-
-
Notifications
You must be signed in to change notification settings - Fork 50
Add DoctrineMongoDB Configuration #740
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Much of this will need to be repeated for the DoctrineExtension - so we should get happy with this and then tackle that next. Also, the XSD was out-of-date when I started and is still very out-dated. |
|
What are the I proposed to work on DoctrineExtension during last meeting but I think I would be better to wait for the feedback on this PR to be able to be consistent. |
|
Woops! For all my care, I was still careless. Ill remove those shortly - they were helping me translate my earlier work. |
|
Rebased and extra files are gone - we're ready for feedback. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should probably be removed (this is my very small contribution to this huge patch ;)).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woops again - it's gone now - thanks for the close eye.
|
Ready to be merged? |
|
Not yet - I'm still working to be sure that there are some OpenSky eyes on this. I'll ping here when that's happened. |
|
This didn't appear to break any of our tests, and the XML config stuff looks good. Keep in mind we have a fairly simple ODM config (one connection and a mapping directory), so your own unit tests likely provide better coverage for that. Great job! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems weird as it still requires to handle both syntaxes in the extension (it should be a normalization work) and the syntaxes cannot be used both which is not handled here.
* stof/assets_url_fix: [FrameworkBundle] fixed tests to conform to new xsd Fixed assets_base_urls configuration
… sompe properties and methods.
* mvrhov/validatorsTransSlo: Draft Slovenian translation
* naderman/watch-debug: [AsseticBundle] Throw exception if --watch is used without --debug.
… the parameter %wildcard% syntax instead. This is best-practice.
… array without the wrapping array. Also rewrote this so that it's more clear.
…ad() method discussing the available options.
…r DoctrineMongoDBExtension.
…s" and "document_managers" wrapper in XML. This was inconsistent and made normalization unnecesarily difficult.
Previously:
<connections>
<connection ...>
<!-- .. -->
</connection>
<connection ...>
<!-- .. -->
</connection>
</connections>
Now:
<connection ...>
<!-- .. -->
</connection>
<connection ...>
<!-- .. -->
</connection>
I believe this is more semantically correct, and it removes code that had to worry about this extra format and normalize it.
…ration class and updated a few default values.
…ache_driver" parameter. This information was set entirely in the DI extension options and then added as a parameter only to be later consumed by the DI extension class. In other words, this should never have been a parameter, or at least it's never been used and treated like a parameter.
…rs(), which is truer to its name. Also mae this function unset the options after their used. This prevents those values from being available later inside the options array and as parameters.
…r, which was never used as a parameter. Now cleaning up connections creation in the DI extension class.
…ded in the Extension and removing two unneeded DIC parameters.
…mall things to match pull request 99 for the Doctrine Configuration class
|
Closed and moved to symfony/symfony so that it could be rebased to the current code: symfony#209 |
Hey guys-
This is a rework of PR 510, which had gone through a lot of evolution.
I think that the tests overall have decent coverage, but they're still a bit of a mess. Certain tests should test the Configuration merging+normalization, and others should feed raw config values (not loaded from an XML or YAML fixture file) into the actual Configuration Extension class and measure the container afterwards. This distinction is still not well-made, and I believe that's repeated for many DI extension classes. This can easily be solved later in a totally BC way.
Comments welcome - especially from the crowd using this bundle in production. See the full.yml file for a somewhat-full example of the config options.
Thanks!