DDC-688: Original Entity Data gets overridden by the change set #846

New Issue

admin · 2026-01-22T12:52:32+01:00

admin commented

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

Originally created by @doctrinebot on GitHub (Jul 12, 2010).

Jira issue originally created by user jasper:

When changing data in an entity, the UnitOfWork will call computeChangeSet on a flush event. If there is a changeset, the original data ($this->*originalEntityData) gets overridden by the new data. However, the *originalEntityData should hold the original data, that was present at the time the entity was reconstituted from the database. This does no longer hold now.

I think this can simply be fixed by commenting this line, however I do not know of any consequences this may bring with it:

$this->_originalEntityData[$oid] = $actualData; (in computeChangeSet, after if( $changeSet ));

Anyway, I ran into this problem while trying to retrieve the original data at the onFlush event of an update.

Originally created by @doctrinebot on GitHub (Jul 12, 2010). Jira issue originally created by user jasper: When changing data in an entity, the UnitOfWork will call computeChangeSet on a flush event. If there is a changeset, the original data ($this->*originalEntityData) gets overridden by the new data. However, the *originalEntityData should hold the original data, that was present at the time the entity was reconstituted from the database. This does no longer hold now. I think this can simply be fixed by commenting this line, however I do not know of any consequences this may bring with it: $this->_originalEntityData[$oid] = $actualData; (in computeChangeSet, after if( $changeSet )); Anyway, I ran into this problem while trying to retrieve the original data at the onFlush event of an update.

admin added the Improvement label 2026-01-22 12:52:32 +01:00

admin commented

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

@doctrinebot commented on GitHub (Aug 8, 2010):

Comment created by romanb:

This is actually currently expected. You can not get access to the original data in the onFlush event right now. I'm not saying that this will never be possible but it is simply the way it works at the moment.

@doctrinebot commented on GitHub (Aug 8, 2010): Comment created by romanb: This is actually currently expected. You can not get access to the original data in the onFlush event right now. I'm not saying that this will never be possible but it is simply the way it works at the moment.

admin commented

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

@doctrinebot commented on GitHub (Dec 8, 2010):

Comment created by jasper:

Does this mean that it is currently impossible to implement a Versionable mechanism using snapshots?

@doctrinebot commented on GitHub (Dec 8, 2010): Comment created by jasper: Does this mean that it is currently impossible to implement a Versionable mechanism using snapshots?

admin commented

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

@doctrinebot commented on GitHub (Dec 9, 2010):

Comment created by @beberlei:

You can hold a map of them yourself if your listener also implements the "postLoad" event:

$entity = $args->getentity();
$this->originalData[spl*object*hash($entity)] = $args->getEntityManager()->getUnitOfWork()->getOriginalData($entity);

@doctrinebot commented on GitHub (Dec 9, 2010): Comment created by @beberlei: You can hold a map of them yourself if your listener also implements the "postLoad" event: ``` $entity = $args->getentity(); $this->originalData[spl*object*hash($entity)] = $args->getEntityManager()->getUnitOfWork()->getOriginalData($entity); ```

admin commented

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

@doctrinebot commented on GitHub (Dec 28, 2010):

Comment created by @beberlei:

Changed into possible improvement for the future

@doctrinebot commented on GitHub (Dec 28, 2010): Comment created by @beberlei: Changed into possible improvement for the future

admin referenced this issue

2026-01-22 16:01:43 +01:00

[PR #846] [CLOSED] joinColumn is not required in manyToMany #8787

admin referenced this issue

2026-01-22 16:01:44 +01:00

[PR #846] joinColumn is not required in manyToMany #8793