-
-
Notifications
You must be signed in to change notification settings - Fork 873
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 missing Doctrine\Common\Persistence\ManagerRegistry class #3684
Conversation
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.
We could/should also choose to conflict with doctrine/persistence < 1.3 - e.g. https://github.com/sensiolabs/SensioFrameworkExtraBundle/pull/691/files#diff-b5d0ee8c97c7abd7e3fa29b9a27d1780R40
The reason is that 1.3 introduced the BC layer. So if you're using 1.3, then you WILL have class aliases for the new Doctrine\Persistence\ManagerRegistry
. If you have an older version, then you would still be using Doctrine\Common\Persistence\ManagerRegistry
. So the conflict guarantees the user will have the new one.
@@ -15,7 +15,7 @@ | |||
|
|||
use ApiPlatform\Core\Metadata\Property\Factory\PropertyMetadataFactoryInterface; | |||
use ApiPlatform\Core\Metadata\Property\PropertyMetadata; | |||
use Doctrine\Common\Persistence\ManagerRegistry; | |||
use Symfony\Bridge\Doctrine\ManagerRegistry; |
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 think you actually want Doctrine\Persistence\ManagerRegistry
- that's the lower-level interface that we're actually requiring. See https://github.com/sensiolabs/SensioFrameworkExtraBundle/pull/691/files#diff-c7d9812ffa6b2809dabcf5120f2d2ec1 as an example
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.
Yes indeed that is a very good point. Using an abstract is way more restrictive than the interface itself. I though the bridge would manage the BC break by using the older or new version but it was an incorrect assumption.
I fear that Doctrine rollback the BC break which will again create some issue. I tried to use the method class_exists before using the use statement but that illegal in PHP. I'm a bit torn of the approach to take to be honest...
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.
It seems the issue also impact Doctrine\Persistence\ObjectManager; (previously Doctrine\Common\Persistence\ObjectManager
).
I need to figure out how to run the tests on my machine before going further (missing mondo db on my machine is the issue I think)
ben@SB3:/tmp/test/test (master) $ vendor/bin/simple-phpunit --stop-on-failure -vvv vendor/api-platform/core/tests/
PHP Fatal error: Trait 'ApiPlatform\Core\Tests\Bridge\Doctrine\Common\Filter\BooleanFilterTestTrait' not found in /tmp/test/test/vendor/api-platform/core/tests/Bridge/Doctrine/MongoDbOdm/Filter/BooleanFilterTest.php on line 25
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.
If you clone the project and if you launch php -d memory_limit=-1 vendor/bin/phpunit tests/Bridge/Doctrine/MongoDbOdm/Filter
without the mongodb extension, there should be no problem.
46e3488
to
cfbf95b
Compare
I'm 👍 for adding a conflict for |
FYI, creating a new api-platform project in this order will work:
|
Yes because, in |
0652da6
to
d84282f
Compare
I don't why it closed automatically, I'm working on @alanpoulin proposal at the moment. |
@walva just adding the conflict is not enough. You should change the typehint like you have done before. |
composer.json
Outdated
@@ -92,7 +92,8 @@ | |||
}, | |||
"conflict": { | |||
"doctrine/common": "<2.7", | |||
"doctrine/mongodb-odm": "<2.0" | |||
"doctrine/mongodb-odm": "<2.0", | |||
"doctrine/persistence": ">1.3" |
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.
"doctrine/persistence": ">1.3" | |
"doctrine/persistence": "<1.3" |
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 got it !
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.
Actually changing the namespace of Doctrine/Common/Persistence to Doctrine/Persistence will break if "doctrine/persistence": "<2.0"
.
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.
But if I do so, I have this error:
composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`.
Your requirements could not be resolved to an installable set of packages.
Problem 1
- api-platform/core 2.5.x-dev conflicts with doctrine/persistence[1.3.0].
- doctrine/persistence 1.3.0 conflicts with api-platform/core[2.5.x-dev].
- Installation request for api-platform/core 2.5.x-dev -> satisfiable by api-platform/core[2.5.x-dev].
- Installation request for doctrine/persistence 1.3.0 -> satisfiable by doctrine/persistence[1.3.0].
Because of this, I'll stick with your proposition but I don't understand the root cause behind the scene.
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.
To avoid doctrine/persistence 2.0 I added
"conflict": {
"doctrine/common": ">=3.0"
}
in my project. Now i can install the api platform. Could this work or do I miss something?
ecd61f7
to
010c8b1
Compare
I update
|
010c8b1
to
9daa91e
Compare
Try again by doing |
9daa91e
to
9501245
Compare
Done ! |
Thanks for helping me @weaverryan and @alanpoulain. It's very motivating and I already learn a lot ! |
* 2.5: feat: bump JS deps Add changelog for 2.5.7 (#3691) fix: fix tests (#3688) Fix missing use statement (#3670) [MongoDB] Fix Behat tests (#3687) Fix missing Doctrine\Common\Persistence\ManagerRegistry class (#3684) [Swagger] Fix that subresource endpoints do not override custom endpoints #3676 - fixed subresource pagination support if primary resource has pagination disabled
Use Symfony Doctrine brigde namespace instead of Doctrine Common namespace for ManagerRegistry class
Description
This issue appreared on Symfony today. It is fixed now, but i'm still unable to run composer require api. I wonder if there is something to do on api-platform side ?
How to reproduce
Create a new Symfony project with composer and add Api-Platform to it:
The last command no longer fail with the same error message as the Symfony linked issue.
Additionally:
I wasn't able to run the tests like described here. I'll have a look asap