DDC-182: Changing entity in preUpdate hook tramples existing changes #228

New Issue

admin · 2026-01-22T12:31:34+01:00

admin commented

2026-01-22 12:31:34 +01:00

Originally created by @doctrinebot on GitHub (Nov 28, 2009).

Jira issue originally created by user amirabiri:

If the object is changed during the pre-update callback, this causes the previous changes to be discarded.

Steps to reproduce:

Create entity with pre-update lifecycle callback
Change property A,
Call flush.
Change property B in pre-update callback

Result is that changes to property A are discarded.

The reason for that is that at the end of Doctrine\ORM\UnitOfWork::_computeEntityChanges() these two statements appear:

$this->_entityChangeSets[$oid] = $changeSet;
$this->_originalEntityData[$oid] = $actualData;

However at the end of Doctrine\ORM\UnitOfWork::computeSingleEntityChangeSet(), which is called after the pre-update callbacks are called, the same thing happens:

$this->_entityChangeSets[$oid] = $changeSet;
$this->_originalEntityData[$oid] = $actualData;

Because the original data is recorded as equal to the state of the object after the first call to _computeEntityChanges(), the call to computeSingleEntityChangeSet() does not detect the original set of changes, it only detects the changes made in the pre-update hooks. But at the same time, both methods completely overwrite the changeset buffer for the entity rather than merge it. The result is that the first changeset is completely discarded.

Originally created by @doctrinebot on GitHub (Nov 28, 2009). Jira issue originally created by user amirabiri: If the object is changed during the pre-update callback, this causes the previous changes to be discarded. Steps to reproduce: - Create entity with pre-update lifecycle callback - Change property A, - Call flush. - Change property B in pre-update callback Result is that changes to property A are discarded. The reason for that is that at the end of Doctrine\ORM\UnitOfWork::_computeEntityChanges() these two statements appear: ``` $this->_entityChangeSets[$oid] = $changeSet; $this->_originalEntityData[$oid] = $actualData; ``` However at the end of Doctrine\ORM\UnitOfWork::computeSingleEntityChangeSet(), which is called after the pre-update callbacks are called, the same thing happens: ``` $this->_entityChangeSets[$oid] = $changeSet; $this->_originalEntityData[$oid] = $actualData; ``` Because the original data is recorded as equal to the state of the object after the first call to _computeEntityChanges(), the call to computeSingleEntityChangeSet() does not detect the original set of changes, it only detects the changes made in the pre-update hooks. But at the same time, both methods completely overwrite the changeset buffer for the entity rather than merge it. The result is that the first changeset is completely discarded.

admin added the Bug label 2026-01-22 12:31:34 +01:00

admin closed this issue

2026-01-22 12:31:34 +01:00

admin commented

2026-01-22 12:31:36 +01:00

@doctrinebot commented on GitHub (Nov 28, 2009):

Comment created by romanb:

Are you sure this is still a valid issue? See DDC-74. This sounds like the same thing.

@doctrinebot commented on GitHub (Nov 28, 2009): Comment created by romanb: Are you sure this is still a valid issue? See [DDC-74](http://www.doctrine-project.org/jira/browse/DDC-74). This sounds like the same thing.

admin commented

2026-01-22 12:31:36 +01:00

@doctrinebot commented on GitHub (Nov 28, 2009):

Comment created by amirabiri:

You are right and I'm sorry. I only went over the list of outstanding issues to avoid double-reporting, didn't occur to me this might have been fixed already.

@doctrinebot commented on GitHub (Nov 28, 2009): Comment created by amirabiri: You are right and I'm sorry. I only went over the list of outstanding issues to avoid double-reporting, didn't occur to me this might have been fixed already.

admin commented

2026-01-22 12:31:36 +01:00

@doctrinebot commented on GitHub (Nov 28, 2009):

Issue was closed with resolution "Duplicate"

@doctrinebot commented on GitHub (Nov 28, 2009): Issue was closed with resolution "Duplicate"

admin referenced this issue

2026-01-22 15:57:24 +01:00

[PR #228] [MERGED] Fixed testsuite #7889

admin referenced this issue

2026-01-22 15:57:25 +01:00

[PR #228] Fixed testsuite #7895

Sign in to join this conversation.