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

[AirBair]

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 ?

[greg0ire]

I think you mean 2.19.4 to 2.19.5

Cc @xificurk

[AirBair]

I think you mean 2.19.4 to 2.19.5

Cc @xificurk

Yes indeed, corrected.

[AirBair]

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

[xificurk]

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) ?