findBy broken for inherited entity property lookups #6124

Closed
opened 2026-01-22 15:27:09 +01:00 by admin · 4 comments
Owner

Originally created by @themizzi on GitHub (Dec 7, 2018).

Originally assigned to: @themizzi on GitHub.

Bug Report

Q. A
BC Break no
Version 2.6.3

Summary

findBy does not work correctly for inherited entities. proof here: https://github.com/themizzi/doctrine-find-by-metadata-bug

Current behavior

If EntityB has a OneToMany relationship to EntityA, and EntityC inherits (via join) from EntityA. If there is no cache, calling $entityBRepo->findBy('entityA' => $newEntityCInstance) works fine. On a subsequent request after cache has already been generated and metadata is lazy loaded, the request breaks. on sqlite this just fails, on MySQL this potentially loads up an incorrect entity.

How to reproduce

Please see link above for an example and reproduction steps.

Expected behavior

Find by can find classes by properties with an inheritance structure at all times.

Originally created by @themizzi on GitHub (Dec 7, 2018). Originally assigned to: @themizzi on GitHub. ### Bug Report | Q. | A |------------ | ------ | BC Break | no | Version | 2.6.3 #### Summary findBy does not work correctly for inherited entities. proof here: https://github.com/themizzi/doctrine-find-by-metadata-bug #### Current behavior If EntityB has a OneToMany relationship to EntityA, and EntityC inherits (via join) from EntityA. If there is no cache, calling `$entityBRepo->findBy('entityA' => $newEntityCInstance)` works fine. On a subsequent request after cache has already been generated and metadata is lazy loaded, the request breaks. on sqlite this just fails, on MySQL this potentially loads up an incorrect entity. #### How to reproduce Please see link above for an example and reproduction steps. #### Expected behavior Find by can find classes by properties with an inheritance structure at all times.
admin added the Bug label 2026-01-22 15:27:09 +01:00
admin closed this issue 2026-01-22 15:27:10 +01:00
Author
Owner

@Ocramius commented on GitHub (Dec 7, 2018):

@themizzi please reproduce this bug in isolation within an integration test, like in https://github.com/doctrine/doctrine2/tree/master/tests/Doctrine/Tests/ORM/Functional/Ticket.

@Ocramius commented on GitHub (Dec 7, 2018): @themizzi please reproduce this bug in isolation within an integration test, like in https://github.com/doctrine/doctrine2/tree/master/tests/Doctrine/Tests/ORM/Functional/Ticket.
Author
Owner

@themizzi commented on GitHub (Dec 7, 2018):

will try to do this weekend. other priorities call for now.

@themizzi commented on GitHub (Dec 7, 2018): will try to do this weekend. other priorities call for now.
Author
Owner

@themizzi commented on GitHub (Dec 8, 2018):

Created regression test. Might have some time to looking into an appropriate fix this weekend.

@themizzi commented on GitHub (Dec 8, 2018): Created regression test. Might have some time to looking into an appropriate fix this weekend.
Author
Owner

@themizzi commented on GitHub (Dec 8, 2018):

Added a fix for this to check if the class is transient before loading metadata during value retrieval.

This fix keeps existing functionality working. However, while looking over this, I see a potential issue with the existing implementation. Matching criteria in findBy does not care if an entity is related or not via an association mapping. It only cares if the metadata for a class is loaded. So if we are performing a findBy on propertyA which has a target entity of EntityA, one can pass in any class that already has metadata loaded, related or not to EntityA, and doctrine will convert the value based on the identifier mapping for that class. I believe performing a check on whether the value class is part of the association mapping should be done here, but that could potentially break existing implementations that have abused the current logic. I will open another issue for that logic if appropriate.

@themizzi commented on GitHub (Dec 8, 2018): Added a fix for this to check if the class is transient before loading metadata during value retrieval. This fix keeps existing functionality working. However, while looking over this, I see a potential issue with the existing implementation. Matching criteria in findBy does not care if an entity is related or not via an association mapping. It only cares if the metadata for a class is loaded. So if we are performing a findBy on `propertyA` which has a target entity of `EntityA`, one can pass in _*any*_ class that already has metadata loaded, related or not to `EntityA`, and doctrine will convert the value based on the identifier mapping for that class. I believe performing a check on whether the value class is part of the association mapping should be done here, but that could potentially break existing implementations that have abused the current logic. I will open another issue for that logic if appropriate.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6124