[PR #6640] #6217 #6284 when hydrating an entity with a composite primary key that is both an EAGER and a LAZY association and also cached, the DefaultQueryCache tries to pass L2 cache implementation detail objects to the UnitOfWork #10079

New Issue

admin · 2026-01-22T16:06:21+01:00

admin commented

2026-01-22 16:06:21 +01:00

Original Pull Request: https://github.com/doctrine/orm/pull/6640

State: closed
Merged: Yes

Fixes #6217
Fixes #6284

This is a proper version of #6284, fixing the deeper problem.

Basically, what is happening is that you have a L2 cached entity class like following:

class A
{
    /** @Id @ManyToOne(targetEntity=b) */
    private $b;
    /** @Id @ManyToOne(targetEntity=c)*/
    private $c;
}

And a DQL query like following:

SELECT a, b
FROM A a
JOIN a.b b

The L2 cache for A.c won't have any information to cache, but it will still contain the identifier for A.c. This means that for that association, a AssociationCacheEntry exists anyway, but no definition in the QueryCacheEntry on how to process it.

I also tried fixing the problem on the other side (where the QueryCacheEntry is produced, rather than consumed), but overfitting it when no association data is actually available causes empty AssociationCacheEntry objects to be hydrated into empty entities (really bad!).

This is just a shotgun patch to fix the problem by iterating over all possible association fields, so if you have any better ideas, please do let me know.

**Original Pull Request:** https://github.com/doctrine/orm/pull/6640 **State:** closed **Merged:** Yes --- Fixes #6217 Fixes #6284 This is a proper version of #6284, fixing the deeper problem. Basically, what is happening is that you have a L2 cached entity class like following: ```php class A { /** @Id @ManyToOne(targetEntity=b) */ private $b; /** @Id @ManyToOne(targetEntity=c)*/ private $c; } ``` And a DQL query like following: ```sql SELECT a, b FROM A a JOIN a.b b ``` The L2 cache for `A.c` won't have any information to cache, but it will still contain the identifier for `A.c`. This means that for that association, a `AssociationCacheEntry` exists anyway, but no definition in the `QueryCacheEntry` on how to process it. I also tried fixing the problem on the other side (where the `QueryCacheEntry` is produced, rather than consumed), but overfitting it when no association data is actually available causes empty `AssociationCacheEntry` objects to be hydrated into empty entities (really bad!). This is just a shotgun patch to fix the problem by iterating over all possible association fields, so if you have any better ideas, please do let me know.

admin added the pull-request label 2026-01-22 16:06:21 +01:00

admin closed this issue

2026-01-22 16:06:21 +01:00

admin referenced this issue

2026-01-22 16:12:51 +01:00

[PR #10079] Merge 2.13.x up into 2.14.x #12072

Sign in to join this conversation.