Entity / property hydration issues after upgrading 2.5.14 => 2.6.0 #5824

Closed
opened 2026-01-22 15:18:54 +01:00 by admin · 11 comments
Owner

Originally created by @holtkamp on GitHub (Dec 25, 2017).

After upgrading from 2.5.14 to 2.6.0 some functionality broke which seems to relate to the hydration of properties of Entities that are part of a (multi-level) DiscriminatorMap:

  • Entity X is fetched by following an association with another Entity Y:
    • 2.5.14 Entity is acquired and all properties as populated / set
    • 2.6.0 Entity is acquired properly, but the properties specific to the Entity are not populated / set. When loading the Entity X directly using the repository and its primary key, all properties are populated.
  • for a certain query the Entity-specific repository returns an result array:
    • 2.5.14 the array contains one entry: an object of class "EntityName"
    • 2.6.0 the array contains one entry: a NULL value

I can reproduce it on my local environment, but can not pinpoint it exactly yet. Will have a look at the current tests and try to come up with a test.

Originally created by @holtkamp on GitHub (Dec 25, 2017). After upgrading from `2.5.14` to `2.6.0` some functionality broke which seems to relate to the hydration of properties of Entities that are part of a (multi-level) DiscriminatorMap: - Entity X is fetched by following an association with another Entity Y: - `2.5.14` Entity is acquired and all properties as populated / set - `2.6.0` Entity is acquired properly, but the properties specific to the Entity are not populated / set. When loading the Entity X directly using the repository and its primary key, all properties are populated. - for a certain query the Entity-specific repository returns an result array: - `2.5.14` the array contains one entry: an object of class "EntityName" - `2.6.0` the array contains one entry: a NULL value I can reproduce it on my local environment, but can not pinpoint it exactly yet. Will have a look at the current tests and try to come up with a test.
admin added the Bug label 2026-01-22 15:18:54 +01:00
admin closed this issue 2026-01-22 15:18:55 +01:00
Author
Owner

@alsar commented on GitHub (Jan 4, 2018):

I just run into the same issue today.
It works with the EntityManager find methods, but it behaves like @holtkamp described with the query builder.

It seems that thew problem is with the query builder, but the generated query is ok.
I tracked it down to a problem with the ResultSetMapping object.

@alsar commented on GitHub (Jan 4, 2018): I just run into the same issue today. It works with the EntityManager `find` methods, but it behaves like @holtkamp described with the query builder. ~~It seems that thew problem is with the query builder, but the generated query is ok.~~ I tracked it down to a problem with the `ResultSetMapping` object.
Author
Owner

@IwfY commented on GitHub (Jan 4, 2018):

For me this happened when I retrieved an object through its repository which had a Many-To-Many aggregate on objects of class A that could also be of its subclasses A1 or A2. The objects from this reference had only the properties populated that class A had.

@IwfY commented on GitHub (Jan 4, 2018): For me this happened when I retrieved an object through its repository which had a Many-To-Many aggregate on objects of class A that could also be of its subclasses A1 or A2. The objects from this reference had only the properties populated that class A had.
Author
Owner

@applike-ss commented on GitHub (Jan 8, 2018):

I have seen the same issue in another scenario.
We use discriminators to determine a type of a row which can has different columns/properties set.
These do look like this:
class X extends AbstractClassY{}
class AbstractClassY extends AbstractClassZ{}
class AbstractClassZ{}

When using the symfony DoctrineParamConverter (which uses the find method of a given repository) it works fine (uses the SimpleObjectHydrator).
When using the Repositories QueryBuilder with $qb->getQuery()->getOneOrNullResult() the ObjectHydrator is used which then thinks it would only need to hydrate properties of AbstractClassZ.

X is defined as ORM Entity.
AbstractClassY is defined as ORM Entity.
AbstractClassZ is defined as ORM Table, ORM Entity, ORM InheritanceType SINGLE_TABLE, ORM DiscriminatorColumn discr (string).

@applike-ss commented on GitHub (Jan 8, 2018): I have seen the same issue in another scenario. We use discriminators to determine a type of a row which can has different columns/properties set. These do look like this: class X extends AbstractClassY{} class AbstractClassY extends AbstractClassZ{} class AbstractClassZ{} When using the symfony DoctrineParamConverter (which uses the find method of a given repository) it works fine (uses the SimpleObjectHydrator). When using the Repositories QueryBuilder with $qb->getQuery()->getOneOrNullResult() the ObjectHydrator is used which then thinks it would only need to hydrate properties of AbstractClassZ. X is defined as ORM Entity. AbstractClassY is defined as ORM Entity. AbstractClassZ is defined as ORM Table, ORM Entity, ORM InheritanceType SINGLE_TABLE, ORM DiscriminatorColumn discr (string).
Author
Owner

@Majkl578 commented on GitHub (Jan 8, 2018):

Could you please try to create a test case that reproduces the bug? It'd be really helpful in order to identify the issue.
You can find examples on https://github.com/doctrine/doctrine2/tree/v2.6.0/tests/Doctrine/Tests/ORM/Functional/Ticket

Thanks.

@Majkl578 commented on GitHub (Jan 8, 2018): Could you please try to create a test case that reproduces the bug? It'd be really helpful in order to identify the issue. You can find examples on https://github.com/doctrine/doctrine2/tree/v2.6.0/tests/Doctrine/Tests/ORM/Functional/Ticket Thanks.
Author
Owner

@holtkamp commented on GitHub (Jan 15, 2018):

@kbond, your test at https://github.com/doctrine/doctrine2/pull/6988 relates to this issue?

@holtkamp commented on GitHub (Jan 15, 2018): @kbond, your test at https://github.com/doctrine/doctrine2/pull/6988 relates to this issue?
Author
Owner

@kbond commented on GitHub (Jan 15, 2018):

@holtkamp yes, I believe so.

@kbond commented on GitHub (Jan 15, 2018): @holtkamp yes, I believe so.
Author
Owner

@holtkamp commented on GitHub (Jan 30, 2018):

@Majkl578, two weeks ago a test was provided by @kbond: https://github.com/doctrine/doctrine2/pull/6988, maybe the "Missing Tests" tag can be removed?

@holtkamp commented on GitHub (Jan 30, 2018): @Majkl578, two weeks ago a test was provided by @kbond: https://github.com/doctrine/doctrine2/pull/6988, maybe the "Missing Tests" tag can be removed?
Author
Owner

@holtkamp commented on GitHub (Feb 5, 2018):

@alsar you wrote

I tracked it down to a problem with the ResultSetMapping object.

Any section in particular? Other info about the potential source is welcome as well...

@holtkamp commented on GitHub (Feb 5, 2018): @alsar you wrote > I tracked it down to a problem with the ResultSetMapping object. Any section in particular? Other info about the potential source is welcome as well...
Author
Owner

@davidomelettes commented on GitHub (Feb 9, 2018):

I've been trying to work out what's happened after a recent upgrade, where repositories of a parent class began to refuse to hydrate entities of a child class. I think I've tracked down the change responsible:

ad3b9de4b8 (diff-d775e8055469374235c04b2cba1b9094R302)

The comparison of discriminators in AbstractHydrator::gatherRowData() is strict and allows for no possibility that the hydrating entity belongs to a child class. I get the feeling it should be doing a !in_array($data[$cacheKeyInfo['discriminatorColumn']], $discriminatorValues) instead of $data[$cacheKeyInfo['discriminatorColumn']] != $cacheKeyInfo['discriminatorValue']?

EDIT: Someone else is already on the case, I see: https://github.com/doctrine/doctrine2/pull/7051

@davidomelettes commented on GitHub (Feb 9, 2018): I've been trying to work out what's happened after a recent upgrade, where repositories of a parent class began to refuse to hydrate entities of a child class. I think I've tracked down the change responsible: https://github.com/doctrine/doctrine2/commit/ad3b9de4b8a9a272fdb8c8183087148dd5b09114#diff-d775e8055469374235c04b2cba1b9094R302 The comparison of discriminators in AbstractHydrator::gatherRowData() is strict and allows for no possibility that the hydrating entity belongs to a child class. I get the feeling it should be doing a `!in_array($data[$cacheKeyInfo['discriminatorColumn']], $discriminatorValues)` instead of `$data[$cacheKeyInfo['discriminatorColumn']] != $cacheKeyInfo['discriminatorValue']`? EDIT: Someone else is already on the case, I see: https://github.com/doctrine/doctrine2/pull/7051
Author
Owner
@holtkamp commented on GitHub (Feb 27, 2018): Seems to be resolved in https://github.com/doctrine/doctrine2/releases/tag/v2.6.1 Also see: https://github.com/doctrine/doctrine2/issues/7059 https://github.com/doctrine/doctrine2/pull/6988 https://github.com/doctrine/doctrine2/pull/7051
Author
Owner

@yosvield commented on GitHub (Feb 27, 2020):

I have the same problem, update version 2.5 to 2.7.1 and not hydrate of properties of Entities that are part of a (multi-level) DiscriminatorMap.
#8042
how it was solved?

@yosvield commented on GitHub (Feb 27, 2020): I have the same problem, update version 2.5 to 2.7.1 and not hydrate of properties of Entities that are part of a (multi-level) DiscriminatorMap. #8042 how it was solved?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5824