DDC-1110: CTI Entities always trigger ->find even when I'm calling ->getReference #1391

New Issue

admin · 2026-01-22T13:12:51+01:00

admin commented

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

Originally created by @doctrinebot on GitHub (Apr 11, 2011).

Originally assigned to: @guilhermeblanco on GitHub.

Jira issue originally created by user @guilhermeblanco:

Suppose we have some CTI mapped entities:

Group <- Company

Without having a given Entity on UnitOfWork IdentityMap, if I do:

$groupProxy = $em->getReference('Group', 1);

It will trigger the ->find (accessing the DB). This is correct on this situation, because the Entity can be either Group or Company. But if I do:

$companyProxy = $em->getReference('Company', 1);

There're no sub-classes anymore (Doctrine doesn't know it, but there are other ways to know), so it should correctly return an instance of CompanyProxy instead of trigger the ->find method.

The solution requires to build the hierarchy of Entities using their ClassMetadata. So it is require to loop though all mapped classes on DiscriminatorMap and check if there's 1 class that subclass the given Entity. If positive, return the result of ->find; otherwise a Proxy can be returned.
This is a non-optimal solution (a better solution would be to cache the hierarchy together with ClassMetadata), but it fixes the issue.

Issue could be considered as major since most CTI scenarios trigger unwanted DB queries, but its usage is so restrict that I left as minor.
We should fix that for 2.1 IMHO.

Originally created by @doctrinebot on GitHub (Apr 11, 2011). Originally assigned to: @guilhermeblanco on GitHub. Jira issue originally created by user @guilhermeblanco: Suppose we have some CTI mapped entities: ``` Group <- Company ``` Without having a given Entity on UnitOfWork IdentityMap, if I do: ``` $groupProxy = $em->getReference('Group', 1); ``` It will trigger the ->find (accessing the DB). This is correct on this situation, because the Entity can be either Group or Company. But if I do: ``` $companyProxy = $em->getReference('Company', 1); ``` There're no sub-classes anymore (Doctrine doesn't know it, but there are other ways to know), so it should correctly return an instance of CompanyProxy instead of trigger the ->find method. The solution requires to build the hierarchy of Entities using their ClassMetadata. So it is require to loop though all mapped classes on DiscriminatorMap and check if there's 1 class that subclass the given Entity. If positive, return the result of ->find; otherwise a Proxy can be returned. This is a non-optimal solution (a better solution would be to cache the hierarchy together with ClassMetadata), but it fixes the issue. Issue could be considered as major since most CTI scenarios trigger unwanted DB queries, but its usage is so restrict that I left as minor. We should fix that for 2.1 IMHO.

admin added the Bug label 2026-01-22 13:12:51 +01:00

admin closed this issue

2026-01-22 13:12:52 +01:00

admin commented

2026-01-22 13:12:55 +01:00

@doctrinebot commented on GitHub (Apr 12, 2011):

Comment created by @beberlei:

Actually doctrine knows it, see the check for $metadata->subClasses, which is always on the grabbed entity. So the behavior is alraedy correct, no way to optimize it.

$companyProxy = $em->getReference('Company', 1);

Does:

$cm = $em->getMetadataFor("Company");
if ($cm->subClasses) // 0 for Company

@doctrinebot commented on GitHub (Apr 12, 2011): Comment created by @beberlei: Actually doctrine knows it, see the check for $metadata->subClasses, which is always on the grabbed entity. So the behavior is alraedy correct, no way to optimize it. ``` $companyProxy = $em->getReference('Company', 1); ``` Does: ``` $cm = $em->getMetadataFor("Company"); if ($cm->subClasses) // 0 for Company ```

admin commented

2026-01-22 13:12:56 +01:00

@doctrinebot commented on GitHub (Apr 12, 2011):

Issue was closed with resolution "Can't Fix"

@doctrinebot commented on GitHub (Apr 12, 2011): Issue was closed with resolution "Can't Fix"

admin referenced this issue

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

[PR #1391] [DDC-3693] Issue with notify change tracking policy #9447

Sign in to join this conversation.