Entity scheduled for deletion and original entity retrieved from database points on the same object since 2.19.5 #7376

New Issue

admin · 2026-01-22T15:50:52+01:00

admin commented

2026-01-22 15:50:52 +01:00

Originally created by @AirBair on GitHub (May 28, 2024).

BC Break Report

Q	A
BC Break	yes ?
Version	2.19.5

Summary

Hi Doctrine team,

When upgrading from doctrine/orm 2.19.4 to 2.19.5, a behavior changed when retrieving an entity scheduled for deletion from the database before the actual flush.

Before 2.19.5, the entity scheduled for deletion and the entity retrieved from the database were 2 different objects with the previous state in the last one, which allowed us to know what was in the entity (e.g. the parent relation in my case), now it seems to be the same object.

It seems related to this PR : https://github.com/doctrine/orm/pull/11428. If I revert the changes locally, i got back the previous behavior.

Previous behavior

Current behavior

How to reproduce

#[AsDoctrineListener(event: Events::onFlush)]
class DummyListener
{
    public function onFlush(OnFlushEventArgs $eventArgs): void
    {
        $objectManager = $eventArgs->getObjectManager();
        $uow = $objectManager->getUnitOfWork();

        foreach ($uow->getScheduledEntityDeletions() as $entity) {
                $originalEntity = $objectManager->getRepository($entity::class)->find($entity->getId());
                dump(['Saved Entity' => $entity]);
                dump(['Original Entity' => $originalEntity]);
        }
    }

Same result if using $uow->getOriginalEntityData($entity) instead of direct call to the database to retrieve original data.

I've seen the issue https://github.com/doctrine/orm/issues/11448, but i don't think that's exactly the same problem.

Any toughts ?

Originally created by @AirBair on GitHub (May 28, 2024).  ### BC Break Report  | Q | A |------------ | ------ | BC Break | yes ? | Version | 2.19.5 #### Summary Hi Doctrine team, When upgrading from doctrine/orm 2.19.4 to 2.19.5, a behavior changed when retrieving an entity scheduled for deletion from the database before the actual flush. Before 2.19.5, the entity scheduled for deletion and the entity retrieved from the database were 2 different objects with the previous state in the last one, which allowed us to know what was in the entity (e.g. the parent relation in my case), now it seems to be the same object. It seems related to this PR : https://github.com/doctrine/orm/pull/11428. If I revert the changes locally, i got back the previous behavior. #### Previous behavior ![doctrine_orm_2 9 4](https://github.com/doctrine/orm/assets/8030342/cfcebd34-5c49-4f5b-9c1c-26e0424eb3e4) #### Current behavior ![doctrine_orm_2 9 5](https://github.com/doctrine/orm/assets/8030342/d2953d3e-cc87-4bd2-b129-51e133730a18) #### How to reproduce ``` #[AsDoctrineListener(event: Events::onFlush)] class DummyListener { public function onFlush(OnFlushEventArgs $eventArgs): void { $objectManager = $eventArgs->getObjectManager(); $uow = $objectManager->getUnitOfWork(); foreach ($uow->getScheduledEntityDeletions() as $entity) { $originalEntity = $objectManager->getRepository($entity::class)->find($entity->getId()); dump(['Saved Entity' => $entity]); dump(['Original Entity' => $originalEntity]); } } ``` Same result if using `$uow->getOriginalEntityData($entity)` instead of direct call to the database to retrieve original data. I've seen the issue https://github.com/doctrine/orm/issues/11448, but i don't think that's exactly the same problem. Any toughts ?

admin commented

2026-01-22 15:50:52 +01:00

@greg0ire commented on GitHub (May 28, 2024):

I think you mean 2.19.4 to 2.19.5

Cc @xificurk

@greg0ire commented on GitHub (May 28, 2024): I think you mean 2.19.4 to 2.19.5 Cc @xificurk

admin commented

2026-01-22 15:50:53 +01:00

@AirBair commented on GitHub (May 28, 2024):

I think you mean 2.19.4 to 2.19.5

Cc @xificurk

Yes indeed, corrected.

@AirBair commented on GitHub (May 28, 2024): > I think you mean 2.19.4 to 2.19.5 > > Cc @xificurk Yes indeed, corrected.

admin commented

2026-01-22 15:50:54 +01:00

@AirBair commented on GitHub (Aug 13, 2024):

Friendly ping @xificurk

I still got the same result by upgrading to v3 and I can't find a way around the problem.

FI, $uow->getOriginalEntityData($entity) give also the same reference

@AirBair commented on GitHub (Aug 13, 2024): Friendly ping @xificurk I still got the same result by upgrading to v3 and I can't find a way around the problem. FI, `$uow->getOriginalEntityData($entity)` give also the same reference

admin commented

2026-01-22 15:50:54 +01:00

@xificurk commented on GitHub (Nov 10, 2024):

Hello, I'm sorry for the delayed response...

Yes, reloading a deleted entity and getting a new fresh instance of it, was a bug that has been fixed by #11428 - see the discussion there and also previous reports of the same underlying problem #6123, #9463.

As far as I can tell $uow->getOriginalEntityData($entity) should be the way to go in your use-case as you've described it. The original data are erased by UoW when the scheduled deletions are executed (the same time as the entity is now removed from identity map).

Same result if using $uow->getOriginalEntityData($entity)

I was not able to reproduce this problem.

@AirBair Can you provide a failing test case demonstrating the problem with $uow->getOriginalEntityData($entity) ?

@xificurk commented on GitHub (Nov 10, 2024): Hello, I'm sorry for the delayed response... Yes, reloading a deleted entity and getting a new fresh instance of it, was a bug that has been fixed by #11428 - see the discussion there and also previous reports of the same underlying problem #6123, #9463. As far as I can tell `$uow->getOriginalEntityData($entity)` should be the way to go in your use-case as you've described it. The original data are erased by UoW when the scheduled deletions are executed (the same time as the entity is now removed from identity map). > Same result if using $uow->getOriginalEntityData($entity) I was not able to reproduce this problem. @AirBair Can you provide a failing test case demonstrating the problem with `$uow->getOriginalEntityData($entity)` ?

admin commented

2026-01-22 15:50:54 +01:00

@AirBair commented on GitHub (Nov 19, 2024):

Hi @xificurk,

Thanks for you reply, better late than never!

When preparing a reproducer, I was able to target the problem a little better.
The behavior does not affect standard deletion cases, but child entities deleted via orphanRemoval specified on the parent.

For context of my use case, a form embedding a collection of children entity, like described here: https://symfony.com/doc/current/form/form_collections.html

Here is a full reproducer : https://github.com/AirBair/doctrine-orm-reproducer

Hope this helps.

@AirBair commented on GitHub (Nov 19, 2024): Hi @xificurk, Thanks for you reply, better late than never! When preparing a reproducer, I was able to target the problem a little better. The behavior does not affect standard deletion cases, but child entities deleted via orphanRemoval specified on the parent. For context of my use case, a form embedding a collection of children entity, like described here: https://symfony.com/doc/current/form/form_collections.html Here is a full reproducer : https://github.com/AirBair/doctrine-orm-reproducer Hope this helps.

admin referenced this issue

2026-01-22 16:07:37 +01:00

[PR #7376] Rebase 2.7 on top of 2.6 #10456

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#7376