-
-
Notifications
You must be signed in to change notification settings - Fork 294
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
Fix how namespace matching happens in SymfonyFileLocator #367
Conversation
The problem was that namespace prefixes can overlap, and for classes that would match more than one prefix only the first prefix would be tested for. This meant that the findMappingFile and fileExists functions would return different results depending on the order of the stored prefixes. For these methods to return the correct values the prefixes must be listed in order of most to least specific. For example ['Vendor\Package\Entities', 'Vendor\Package\Entities\Blog'] would return the wrong result whereas ['Vendor\Package\Entities\Blog', 'Vendor\Package\Entities'] would return the correct one.
Hello, thank you for creating this pull request. I have automatically opened an issue http://www.doctrine-project.org/jira/browse/DCOM-286 We use Jira to track the state of pull requests and the versions they got |
Has anybody had a chance to look at this? This is a very simple PR and it's very disheartening to see it languish for 4 months without any feedback either way. |
@ptlis didn't check so far, sorry. Thanks for the ping though. What I see is that a test is missing here. |
Just re-checked this: it needs an additional test case for the scenario where multiple paths are mapped. |
👍 thanks @Ocramius , I'll try and find time to look at this over the weekend. |
Ensures that the prefix to path mappings can be provided in an arbitrary order. Previously these had to be in most to least specific ordering. For example with the prefix mapping ['\Foo\Bar' => '.', '\Foo' => '../'] classes in the \Foo\Bar namespace would be found, but on providing the prefix mapping ['\Foo' => '../', '\Foo\Bar' => '.'] these classes could not be found.
I've added tests to ensure that the prefix ordering no longer makes a difference, is there anything else I need to do to get this into a mergeable state? |
…hing-2.5' into 2.5 Close #367
…hing-2.6' into 2.6 Close #367
The problem was that namespace prefixes can overlap, and for classes
that would match more than one prefix only the first prefix would be
tested for. This meant that the findMappingFile and fileExists functions
would return different results depending on the order of the stored
prefixes.
For these methods to return the correct values the prefixes must be
listed in order of most to least specific. For example
would return the wrong result whereas
would return the correct one.
This changeset simply allows the class to be compared to more than one prefix, and updates one test as an exception message has changed.