Skip to content
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

Upgrading to doctrine/orm 2.7.3 with doctrine/common 3.0 causes Class not found errors #1197

Closed
trickeyone opened this issue Aug 20, 2020 · 17 comments

Comments

@trickeyone
Copy link

After issuing a composer update on doctrine/* on a newly upgrade Symfony 5 project, during the cache warmup I'm getting the below error when using doctrine/common 3.0

Fatal error: Uncaught Error: Class 'Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain' not found in /my-project/app/var/cache/dev/ContainerPxbhKBF/App_KernelDevDebugContainer.php on line 1420

Error: Class 'Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain' not found in /my-project/app/var/cache/dev/ContainerPxbhKBF/App_KernelDevDebugContainer.php on line 1420

Call Stack:
    0.0013     404360   1. {main}() /my-project/app/bin/console:0
    0.0431    2139208   2. Symfony\Bundle\FrameworkBundle\Console\Application->run() /my-project/app/bin/console:38
    0.0831    2309936   3. Symfony\Bundle\FrameworkBundle\Console\Application->doRun() /my-project/app/vendor/symfony/console/Application.php:140
    0.0831    2309936   4. Symfony\Bundle\FrameworkBundle\Console\Application->registerCommands() /my-project/app/vendor/symfony/framework-bundle/Console/Application.php:74
    0.0831    2309936   5. App\Kernel->boot() /my-project/app/vendor/symfony/framework-bundle/Console/Application.php:168
    0.1086    3312160   6. App\Kernel->initializeContainer() /my-project/app/vendor/symfony/http-kernel/Kernel.php:131
    9.1711   59944952   7. Symfony\Component\HttpKernel\CacheWarmer\CacheWarmerAggregate->warmUp() /my-project/app/vendor/symfony/http-kernel/Kernel.php:572
    9.1748   60014128   8. ContainerPxbhKBF\getCacheWarmerService::ContainerPxbhKBF\{closure:/my-project/app/var/cache/dev/ContainerPxbhKBF/getCacheWarmerService.php:23-33}() /my-project/app/vendor/symfony/http-kernel/CacheWarmer/CacheWarmerAggregate.php:90
    9.1748   60014128   9. ContainerPxbhKBF\App_KernelDevDebugContainer->load() /my-project/app/var/cache/dev/ContainerPxbhKBF/getCacheWarmerService.php:25
    9.1751   60031800  10. ContainerPxbhKBF\getValidator_Mapping_CacheWarmerService::do() /my-project/app/var/cache/dev/ContainerPxbhKBF/App_KernelDevDebugContainer.php:840
    9.1752   60031880  11. ContainerPxbhKBF\App_KernelDevDebugContainer->getValidator_BuilderService() /my-project/app/var/cache/dev/ContainerPxbhKBF/getValidator_Mapping_CacheWarmerService.php:24
    9.1812   60396792  12. ContainerPxbhKBF\App_KernelDevDebugContainer->getDoctrine_Orm_DefaultEntityManagerService() /my-project/app/var/cache/dev/ContainerPxbhKBF/App_KernelDevDebugContainer.php:2892

If I force doctrine/common to ^2.7 <3.0, the errors go away. Maybe doctrine/orm:2.x shouldn't be doctrine/common:^2.11 || ^3.0 just yet?

@greg0ire
Copy link
Member

greg0ire commented Aug 21, 2020

Not sure it has to do with doctrine/orm: the issue is in var/cache, not in vendor/doctrine/orm, so I'd say what is wrong is the service definition of getDoctrine_Orm_DefaultEntityManagerService… so the issue would be in DoctrineBundle, maybe? What version of DoctrineBundle are you using? I want to know if you have this commit: #1146

Also , a good way to find the offending package would be to grep the name in the error message in vendor

@trickeyone
Copy link
Author

@greg0ire It's doctrine/orm specifying a requirement for doctrine/common at ^2.11 || ^3.0. When I prevent 3.0 from being installed, everything's fine. When 3.0 is installed, that's when I get the errors.

So, my suggestion was to not have the ^2.11 || ^3.0, but to only have ^2.11. Including 3.0 at this point, when the existing doctrine/orm code (or maybe one of the other doctrine packages) may not be in 100% alignment with doctrine/common:^3.0 seems to possibly be causing some kind of conflict. Between testing, I always made sure the cache directory was clean (i.e. I did an rm -rf on the cache directory contents). So the issue does not reside inside the var/cache directory, since those are all on-demand generated by Symfony. The only reason it could possibly be pulling something incorrectly, would be due to something either in the Symfony code or the Doctrine code, from what I was able to gather.

At this point, I'm assuming it's simply a conflict between doctrine/common at ^2.11 and ^3.0. Other than that, I can't really speculate.

I included the only stacktrace that I had available. The errors go away when I exclude doctrine/common:^3.0 from being installed.

In the end, I had to exclude doctrine/common:^3.0 from being installed by explicitly requiring doctrine/common:^2.11 <3.0 in my project, to prevent the error from occurring.

@greg0ire
Copy link
Member

greg0ire commented Aug 22, 2020

or maybe one of the other doctrine packages

The issue is with other Doctrine packages, they are the one that should be fixed.

Between testing, I always made sure the cache directory was clean (i.e. I did an rm -rf on the cache directory contents). So the issue does not reside inside the var/cache directory, since those are all on-demand generated by Symfony.

What I meant by that was of course not that you wrote something wrong by hand in your cache. The cache is generated, and it's not generated from doctrine/orm, which does not know about the cache. The only Doctrine package that knows about the cache is DoctrineBundle (because it integrates Doctrine with Symfony).

The only reason it could possibly be pulling something incorrectly, would be due to something either in the Symfony code or the Doctrine code, from what I was able to gather.

Yes, more precisely, from DoctrineBundle

Also , a good way to find the offending package would be to grep the name in the error message in vendor

Can you please do that? I think it will show the wrong name in vendor/doctrine/doctrine-bundle

I want to know if you have this commit: #1146

Can you please not ignore my questions? It's really rude.

@trickeyone
Copy link
Author

@greg0ire Sorry, I wasn't ignoring your questions, I just got lost in my own thoughts and attempts to explain, since I believed that I supplied more than enough information in my initial post. Which I am now having to reiterate.

The error message appears to be a core PHP error during autoloading, which would appear to say that the class is missing. Either from not being included in the autoload definitions or something else. Also, the message "Class 'X' not found" seems to be very generic. When I looked in the files on the stacktrace, I found no mention of the class in question. I then also did a full grep -r "not found" on the entire cache directory and nothing was returned. Which tells me it's not something coming from there.

As to #1146, I don't really know. From what I see, that's from a doctrine:1.12.x branch PR? I'm on doctrine/doctrine-bundle:2.1.0. If there is more of a connection, please provide it as I don't see the correlation. There isn't much of a discussion on that PR. All I can see from it is that a definition was changed in the orm.xml config. Maybe it wasn't properly merged into the 2.x branch after merging into 1.x?

When I said I did an update to doctrine/*, I mean I literally did a composer update "doctrine/*". So all doctrine packages should have been updated to their appropriately supported versions. That's when I got the error. It took me a while to track it down to being that doctrine/orm specified a requirement for doctrine/comment:^2.11 || ^3.0.

I do know that when I did the above, the error goes away. So maybe there is an issue, as I have stated, to allowing doctrine/common:^3.0.

I would appreciate it if you did not ignore me stating this multiple times that the issue goes away when I do the version limit. That also is really rude. I spent multiple hours trying to track down this issue that came down to a simple enough thing, that you then appear to have dismissed without much thought. I would appreciate it if you read what I have said instead of glancing over it. I really do appreciate what the Doctrine team does and the work that you all do, but when someone reports an issue, please do not simply dismiss it out of hand.

@greg0ire
Copy link
Member

I then also did a full grep -r "not found" on the entire cache directory and nothing was returned.

The cache calls code from vendor, so that's expected. The grep I was suggested was more like this: grep -rn -F MappingDriverChain vendor/doctrine/doctrine-bundle.

As to #1146, I don't really know. From what I see, that's from a doctrine:1.12.x branch PR? I'm on doctrine/doctrine-bundle:2.1.0. If there is more of a connection, please provide it as I don't see the correlation. There isn't much of a discussion on that PR. All I can see from it is that a definition was changed in the orm.xml config. Maybe it wasn't properly merged into the 2.x branch after merging into 1.x?

6448be3

If you look at the only commit in there, you will see that it landed in 2.1.0, so you should in fact be good. I was expecting the change in orm.xml to fix your issue, but apparently it doesn't. I guess a better grep would then be

grep -rnF 'Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain' vendor

I do know that when I did the above, the error goes away. So maybe there is an issue, as I have stated, to allowing doctrine/common:^3.0.

Maybe indeed, or maybe not, you may run composer outdated to see if you have the latest versions of everything or if in fact, your a limited by a constraint you are not aware of.

I would appreciate it if you did not ignore me stating this multiple times that the issue goes away when I do the version limit. That also is really rude.

That wasn't a question was it? Do all your sentences warrant an answer? Only questions do. You asked one, and I answered it. That wasn't good enough for you apparently, you want the solution now, by having me doing all the work, you don't want to have to do additional investigating. You're trying to get back at me for calling you rude, that's all.

I spent multiple hours trying to track down this issue that came down to a simple enough thing, that you then appear to have dismissed without much thought.

It's great, but you will certainly understand that it will be hard for me to be impressed by that after all the hours I spend on Doctrine… And you're right I appear to have dismissed it without much though. In reality, I have kept it in my mind for when the solution is clearer. Wouldn't want to spend to much brainpower investigating all potential sources when the issue can be narrowed down with a simple grep.

I really do appreciate what the Doctrine team does and the work that you all do

Do you? Do you really? Would you call yourself grateful for getting help directly from Doctrine on a Saturday? Or are you in fact demanding to be helped as if you were a paying customer, complaining that my answer is not good enough for your taste?

Fair warning: either we both re-focus on the problem or I lock this conversation as "too heated". So you have the choice between "help that is not perfect" or "no help"

@trickeyone
Copy link
Author

trickeyone commented Aug 22, 2020

Do you? Do you really? Would you call yourself grateful for getting help directly from Doctrine on a Saturday? Or are you in fact demanding to be helped as if you were a paying customer, complaining that my answer is not good enough for your taste?

I'll address this first since it appears poignant. Yes, I absolutely appreciate all the work that the Doctrine team does, yourself included. I am not, nor would I ever, demand to be helped; on a Saturday or any other time for an open-source project that is supplied free of charge to the community. I have been a benefactor, as well as a contributor, for more than a decade of this project. I had no expectations of receiving this speedy of a response, for which I am very grateful. I simply did not expect to be called "rude" in a response, when all I did was not include an answer to all of your questions in my response. For which, I again apologize.

Now, with that out of the way, I am more than happy to refocus on the issue at hand.

To the composer outdated, I did complete this a couple weeks ago as part of my preparing to upgrade form Symfony 4.4 to 5.1. I upgraded all packages where possible. I know that none are severely outdated, only minor/revision differences, doctrine/common being the exclusion.

However, I ran it again to double-check. I ran it with both doctrine/common ^2.11 || ^3.0 and ^2.11:
^2.11 || ^3.0:

doctrine/doctrine-bundle            2.0.2              2.1.0              Symfony DoctrineBundle
doctrine/inflector                  1.4.3              2.0.3              PHP Doctrine Inflector is a small library that c...
ocramius/proxy-manager              2.8.0              2.8.1              A library providing utilities to generate, insta...

^2.11:

doctrine/common                     2.13.3             3.0.2              PHP Doctrine Common project is a library that provides additional functi...
doctrine/inflector                  1.4.3              2.0.3              PHP Doctrine Inflector is a small library that can perform string manipu...
doctrine/persistence                1.3.8              2.0.0              The Doctrine Persistence project is a set of shared interfaces and funct...
ocramius/proxy-manager              2.8.0              2.8.1              A library providing utilities to generate, instantiate and generally ope...

I ran the suggested grep (grep -rnF 'Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain' vendor) on the checked-out 2.7.3 version and this was the only result returned:

vendor/doctrine/persistence/lib/Doctrine/Persistence/Mapping/Driver/MappingDriverChain.php:148:class_exists(\Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain::class);

I then removed the <3.0 limitation and re-ran the grep and received this result:

vendor/doctrine/doctrine-bundle/Resources/config/orm.xml:32:        <parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain</parameter>

When I ran composer update after removing the limitation, I noticed a downgrade in doctrine/doctrine-bundle:

- Removing doctrine/sql-formatter (1.1.1)
  - Updating doctrine/persistence (1.3.8 => 2.0.0): Loading from cache
  - Updating doctrine/common (2.13.3 => 3.0.2): Loading from cache
  - Installing jdorn/sql-formatter (v1.2.17): Downloading (100%)         
  - Downgrading doctrine/doctrine-bundle (2.1.0 => 2.0.2): Loading from cache

@greg0ire
Copy link
Member

greg0ire commented Aug 22, 2020

For which, I again apologize.

Apology accepted. On my end, my answers may be far from perfect, but, you will get speedy support indeed, so that something, I hope it balances it out for you. Let's start over.

I noticed a downgrade in doctrine/doctrine-bundle:

Nice work. There is the issue. Can you try running composer why-not doctrine/doctrine-bundle 2.1.0?

@greg0ire
Copy link
Member

greg0ire commented Aug 22, 2020

You can also try adding a constraint forcing the installation of v2.1.0 of the bundle, but I'm not sure that will work. If it does work, I guess it will result in the downgrade of some other package.

@trickeyone
Copy link
Author

$ composer why-not doctrine/doctrine-bundle 2.1.0 
doctrine/doctrine-bundle  2.1.0        requires          doctrine/persistence (^1.3.3)                  
my/app                    master  does not require  doctrine/persistence (but 2.0.0 is installed) 

@trickeyone
Copy link
Author

I attempted to add the constraint for doctrine/doctrine-bundle:^2.1.0 and it resulted in composer erroring out with no solution available.

$ COMPOSER_MEMORY_LIMIT=-1 composer require doctrine/doctrine-bundle:^2.1.0
./composer.json has been updated
Loading composer repositories with package information                                          Updating dependencies (including require-dev)         
Restricting packages listed in "symfony/symfony" to "^5.1"
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Conclusion: don't install doctrine/doctrine-bundle 2.1.0
    - don't install doctrine/doctrine-bundle 2.2.x-dev|install doctrine/doctrine-bundle dev-master
    - Conclusion: don't install doctrine/doctrine-bundle dev-master
    - Conclusion: remove doctrine/persistence 2.0.0
    - Installation request for doctrine/doctrine-bundle ^2.1.0 -> satisfiable by doctrine/doctrine-bundle[2.1.0, 2.1.x-dev, 2.2.x-dev].
    - Conclusion: don't install doctrine/persistence 2.0.0
    - doctrine/doctrine-bundle 2.1.x-dev requires doctrine/persistence ^1.3.3 -> satisfiable by doctrine/persistence[1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.3.8, 1.3.x-dev, 1.4.x-dev].
    - Can only install one of: doctrine/persistence[1.3.3, 2.0.0].
    - Can only install one of: doctrine/persistence[1.3.4, 2.0.0].
    - Can only install one of: doctrine/persistence[1.3.5, 2.0.0].
    - Can only install one of: doctrine/persistence[1.3.6, 2.0.0].
    - Can only install one of: doctrine/persistence[1.3.7, 2.0.0].
    - Can only install one of: doctrine/persistence[1.3.8, 2.0.0].
    - Can only install one of: doctrine/persistence[1.3.x-dev, 2.0.0].
    - Can only install one of: doctrine/persistence[1.4.x-dev, 2.0.0].
    - Installation request for doctrine/persistence (locked at 2.0.0) -> satisfiable by doctrine/persistence[2.0.0].

@greg0ire
Copy link
Member

greg0ire commented Aug 22, 2020

I believe this will fix your issue: #1181

You can carry the PR if you want it to go faster.

@greg0ire greg0ire transferred this issue from doctrine/orm Aug 22, 2020
@trickeyone
Copy link
Author

Looks good. My projects don't explicitly require doctrine/persistence, so I'm assuming there shouldn't be any issue with the change from ^1.3.3 to ^1.3.3 | 2.0. I'll keep any eye out for a new release for doctrine/doctrine-bundle to verify.

Thank you very much for the assistance, @greg0ire.

@greg0ire
Copy link
Member

I just released 2.1.1, that should fix the issue.

@trickeyone
Copy link
Author

Awesome! Thank you very much!

@trickeyone
Copy link
Author

Sorry, meant to add this yesterday. I was able to successfully upgrade doctrine/doctrine-bundle to 2.1.2 and doctrine/persistence to 2.0.0. Thanks once again for all the help, @greg0ire !!

@temuraru
Copy link

Off-topic: Thank you both (greg0ire/trickeyone) for showing this kind of fair-play and for calming a heated arguments' thread - it's so uncommon and nice, that it ~blew my mind! (it shouldn't have, because this kind of behavior should be the norm, but unfortunately, it isn't - either on Github or Reddit or HN or wherever...)

Orkin added a commit to Orkin/oauth2-bundle that referenced this issue Apr 6, 2021
Orkin added a commit to Orkin/oauth2-bundle that referenced this issue Apr 6, 2021
Orkin added a commit to Orkin/oauth2-bundle that referenced this issue Apr 12, 2021
Orkin added a commit to Orkin/oauth2-bundle that referenced this issue Apr 12, 2021
* Remove timecop and replace DateTimeImmutable by Chronos (same interface)

* fix tests errors

* Add delta to integration/acceptance test for token expiration

* fix chronos in require dependencies

* Change Chronos by Carbon

* add php 8 and symfony 5.2

* drop support of php 7.2 and add some fixes in Dockerfile

* add xdebug mode coverage

* bump php cs fixer version

* fix doctrine common doctrine/DoctrineBundle#1197

* fix php cs fixer, disable no_trailing_whitespace_in_string new rule

* fix doctrine mapping exception https://github.com/doctrine/orm/releases/tag/2.8.1

* fix oauth2-server enforcement with client without redirect_uri https://github.com/thephpleague/oauth2-server/releases/tag/8.2.4

* drop support of doctrine bundle 1.8

* revert drop of php 7.2
@hoangdhtn
Copy link

how to install old version Doctrine ?

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

No branches or pull requests

4 participants