Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

Merged
15 commits merged into from
Mar 9, 2011
Merged

Add DoctrineMongoDB Configuration #209

15 commits merged into from
Mar 9, 2011

Conversation

weaverryan
Copy link
Member

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.

  • New Configuration class for DoctrineMongoDBExtension
  • The cleanup of the class, involving removal of getParameter() calls and the removal of some parameters
  • The removal of the extra "connections" and "document_managers" node in XML. This was redundant and made normalization a huge pain. This breaks BC, but I believe is more correct. (weaverryan@a1ecb92)

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!

… 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.
…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(
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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

@fabpot
Copy link
Member

fabpot commented Mar 9, 2011

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.

@weaverryan
Copy link
Member Author

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.

SofHad pushed a commit to SofHad/symfony that referenced this pull request Oct 12, 2015
…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
jderusse pushed a commit to jderusse/symfony that referenced this pull request Mar 30, 2020
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants