[PR #10884] Fix broken changeset computation for entities loaded through fetch=EAGER + using inheritance #12676

New Issue

admin · 2026-01-22T16:14:50+01:00

admin commented

2026-01-22 16:14:50 +01:00

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

State: closed
Merged: Yes

#10880 reports a case where the changes from #10785 cause entity updates to be missed.

Upon closer inspection, this change seems to be causing it:

https://github.com/doctrine/orm/pull/10785/files#diff-55a900494fc8033ab498c53929716caf0aa39d6bdd7058e7d256787a24412ee4L2990-L3003

The code was changed to use registerManaged() instead, which basically does the same things, but (since #10785) also includes an additional check against duplicate entity instances.

But, one detail slipped through tests and reviews: registerManaged() also updates \Doctrine\ORM\UnitOfWork::$originalEntityData, which is used to compute entity changesets. An empty array [] was passed for $data here.

This will make the changeset computation assume that a partial object was loaded and effectively ignore all field updates here:

a616914887/lib/Doctrine/ORM/UnitOfWork.php (L762-L764)

I think that, effectively, it is sufficient to call registerManaged() only in the two cases where a proxy was created.

Calling registerManaged() with [] as data for a proxy object is consistent with e. g. \Doctrine\ORM\EntityManager::getReference().

In the case that a full entity has to be loaded, we need not call registerManaged() at all, since that will already happen inside EntityManager::find() (or, more specifically, UnitOfWork::createEntity() called inside it).

Note that the test case has to make some provisions so that we actually reach this case:

Load an entity that uses fetch="EAGER" on a to-one association
That association being against a class that uses inheritance (why's that?)

**Original Pull Request:** https://github.com/doctrine/orm/pull/10884 **State:** closed **Merged:** Yes --- #10880 reports a case where the changes from #10785 cause entity updates to be missed. Upon closer inspection, this change seems to be causing it: https://github.com/doctrine/orm/pull/10785/files#diff-55a900494fc8033ab498c53929716caf0aa39d6bdd7058e7d256787a24412ee4L2990-L3003 The code was changed to use `registerManaged()` instead, which basically does the same things, but (since #10785) also includes an additional check against duplicate entity instances. But, one detail slipped through tests and reviews: `registerManaged()` also updates `\Doctrine\ORM\UnitOfWork::$originalEntityData`, which is used to compute entity changesets. An empty array `[]` was passed for $data here. This will make the changeset computation assume that a partial object was loaded and effectively ignore all field updates here: https://github.com/doctrine/orm/blob/a616914887ea160db4158d2c67752e99624f7c8a/lib/Doctrine/ORM/UnitOfWork.php#L762-L764 I think that, effectively, it is sufficient to call `registerManaged()` only in the two cases where a proxy was created. Calling `registerManaged()` with `[]` as data for a proxy object is consistent with e. g. `\Doctrine\ORM\EntityManager::getReference()`. In the case that a full entity has to be loaded, we need not call `registerManaged()` at all, since that will already happen inside `EntityManager::find()` (or, more specifically, `UnitOfWork::createEntity()` called inside it). Note that the test case has to make some provisions so that we actually reach this case: * Load an entity that uses `fetch="EAGER"` on a to-one association * That association being against a class that uses inheritance (why's that?)

admin added the pull-request label 2026-01-22 16:14:50 +01:00

admin closed this issue

2026-01-22 16:14:50 +01:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#12676