mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
Call to a member function removeQueryCacheProfile() on null #7221
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @cmodijk on GitHub (Sep 14, 2023).
Bug Report
Summary
I have create a this example repository to reproduce the error. When i grap this project using PHP
7.4and al the dependencies in it I get this error.The first call to the method tries to to connect to a database. When i ignore this and then refresh the page i get this error. It seems to happen after the cache is stored on disk and then it is tried to be reloaded.
On the same error i already found https://github.com/doctrine/DoctrineBundle/issues/1654 and https://github.com/doctrine/orm/pull/10684 but this pull request does not fixes it. After debugging when i remove the
__unserializemethod fromlib/Doctrine/ORM/Query/ParserResult.phpit seems to work not sure what is going on here.Current behavior
Results in a error
How to reproduce
Expected behavior
To not have a error.
@greg0ire commented on GitHub (Sep 14, 2023):
Reproduced with PHP 8 (you can drop the php 7 constraint for your reproducer).
Here is the full stack trace after I add a return type to
getSQLExecutor():@cmodijk commented on GitHub (Sep 14, 2023):
I removed the
7.4part, i also just noticed that it does not seem to happen when usingsymfony/symfony^5.4@cmodijk commented on GitHub (Sep 14, 2023):
It is also weird that the
__unserializemethod in\Doctrine\ORM\Query\ParserResultis called with this input. This keys don't align with what the method is getting out of it.@greg0ire commented on GitHub (Sep 14, 2023):
Here is what it looks like with symfony 5.4 (contains non-printable chars):
The method seems to handle 2 different serialization formats, and this would be a 3rd one.
@andrew-demb commented on GitHub (Sep 14, 2023):
Adding here
858b01f85e/lib/Doctrine/ORM/Query/ParserResult.php (L142-L148)an additional key check -?? $data[self::class][$property]fixes the issue for me (Symfony 4.4, PHP 7.4.29,doctrine/orm2.16.2)@greg0ire commented on GitHub (Sep 15, 2023):
That makes sense… would you mind contributing that? Also, I don't fully understand why this has to do with Symfony… does Symfony decide what serialization format is in use? 🤔
Cc @derrabus , I think we should either revert the addition of the method, or apply @andrew-demb's suggestion.
@cmodijk commented on GitHub (Sep 15, 2023):
I don't believe so it should alway be the same. But this location call's the
__unserializedirectly which gives the wrong format if you ask me. Maybe it is a bug in the Symfony unserializer?When i update to Symfony
5.4the input seems to be correct.@cmodijk commented on GitHub (Sep 15, 2023):
Inside the dumped cache file i just found this diff Symfony seemed to have fixed the dumper. Seems that this is the changed we are looking for
6d8a363a15or6ccb85e185@greg0ire commented on GitHub (Sep 15, 2023):
@cmodijk thanks for the investigation. Can you try @andrew-demb solution? If it works for you, can you please contribute it? Another "solution" would be to drop support for Symfony 4, which is in security fixes only mode, but that would leave you in a bad situation.
@cmodijk commented on GitHub (Sep 15, 2023):
I just created https://github.com/doctrine/orm/pull/10948. It would leave us in a bad situation if Symfony 4 support is dropped but we are in the process of upgrading all of our old Symfony projects. At this time we disabled the query caching to allow us to upgrade everything else. But the issue here for us is we are not sure how bug this impact is on preformance.
@cmodijk commented on GitHub (Jan 12, 2024):
Fixed by https://github.com/doctrine/orm/pull/10948