-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Add DoctrineMongoDB Configuration #209
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
… 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
// if no "connections" were given, setup the default connection | ||
if (!isset($config['connections']) || !$config['connections']) { | ||
$defaultName = $config['default_connection']; | ||
$config['connections'] = array($defaultName => array( |
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 is a normalization work and should be done in the Configuration class. Thus it would allow to merge things well when using the short syntax in a file and the expanded one in another one. Look at my PR for DoctrineBundle. I implemented this.
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.
I agree in principal, but the implementation is honestly a bit ugly and confusing, which is not your fault, just a byproduct of what you're trying to accomplish (https://github.com/symfony/symfony/pull/99/files#L0R52).
I'm also not sure I agree that the merging is a good idea. Does this mean that if I specify the "host" using the short syntax in one file that it will merge onto the "default" connection that's spelled out in the long syntax of another file? If so, I think it makes more sense to let the individual configuration values all merge together and then - at the end of everything - decide whether or not we should use the short syntax or if the long syntax has been provided.
Thoughts?
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.
The issue is also validation. Keeping both syntaxes does not allow to define required parameters but some of them are required.
IMHO the ugly thing is providing a short syntax. Even the test uses the expanded syntax when loading a single connection or entity manager. And the expanded syntax is not much complicated than the short one. See stof/symfony-docs@a3d7433 to compare them.
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.
Ok, I definitely agree with you there. As you probably agree (now that you've done a few Configuration classes), we're allowing lots of different ways to specify config in many cases for no real gain. Perhaps you and I should craft and independent pull request after these two are merged in that removes the short option. We can get discussion on just that one topic.
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.
I will send a mail on the ML to discuss this topic with the community
I'd like to merge it ASAP with its sister PR (99). Is it possible now? I mean, even if there are still some minor issues here and there, we can probably tweak them later on. |
Yes, I think we're ready - we won't discover any more problems until we merge and people run into them. Test coverage is pretty solid and the issue that stof and I are discussing boils down to a fairly minor issue of how connections and managers should merge in an edge case. |
…e listener (javiereguiluz) This PR was squashed before being merged into the master branch (closes symfony#209). Discussion ---------- Simplified the code of the RedirectToPreferredLocale listener Some minor changes after the merge of symfony#199. @voronkovich could you please review that this simplifications don't break your code? Thanks! Commits ------- 5dc5e33 Simplified the code of the RedirectToPreferredLocale listener
Fix illuminate/* links
Hey guys-
This was brought over from fabpot#740 and has been rebased to the latest. This is a sister pull request of https://github.com/symfony/symfony/pull/99/files.
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 - fwiw, jmikola from OpenSky had kicked the tires on this a little bit a couple of weeks ago for me.
Thanks!