DDC-3160: Regression in reComputeSingleEntityChangeset #3917

New Issue

admin · 2026-01-22T14:31:25+01:00

admin commented

2026-01-22 14:31:25 +01:00

Originally created by @doctrinebot on GitHub (Jun 10, 2014).

Originally assigned to: @Ocramius on GitHub.

Jira issue originally created by user flack:

I just updated from 2.4.2 to 2.4.3 and watched most of my code break. I haven't found out all the details, but what happens is that entities passed to $em->persist() end up in UoW's entityUpdates array (even though they don't have an identity).

I've found out that the issue goes away when I uncomment this line:

https://github.com/doctrine/doctrine2/blob/v2.4.3/lib/Doctrine/ORM/UnitOfWork.php#L933

I'll try to debug this further when I have some time, and will add comments then

Originally created by @doctrinebot on GitHub (Jun 10, 2014). Originally assigned to: @Ocramius on GitHub. Jira issue originally created by user flack: I just updated from 2.4.2 to 2.4.3 and watched most of my code break. I haven't found out all the details, but what happens is that entities passed to $em->persist() end up in UoW's entityUpdates array (even though they don't have an identity). I've found out that the issue goes away when I uncomment this line: https://github.com/doctrine/doctrine2/blob/v2.4.3/lib/Doctrine/ORM/UnitOfWork.php#L933 I'll try to debug this further when I have some time, and will add comments then

admin added the Bug label 2026-01-22 14:31:25 +01:00

admin closed this issue

2026-01-22 14:31:26 +01:00

admin commented

2026-01-22 14:31:26 +01:00

@doctrinebot commented on GitHub (Jun 10, 2014):

is referenced by DDC-2996: UnitOfWork::recomputeSingleEntityChangeSet() will not add a new change set

@doctrinebot commented on GitHub (Jun 10, 2014): - is referenced by [DDC-2996: UnitOfWork::recomputeSingleEntityChangeSet() will not add a new change set](http://www.doctrine-project.org/jira/browse/DDC-2996)

admin commented

2026-01-22 14:31:26 +01:00

@doctrinebot commented on GitHub (Jun 10, 2014):

Comment created by @ocramius:

Do you have any listeners interacting with your changesets?

@doctrinebot commented on GitHub (Jun 10, 2014): Comment created by @ocramius: Do you have any listeners interacting with your changesets?

admin commented

2026-01-22 14:31:27 +01:00

@doctrinebot commented on GitHub (Jun 10, 2014):

Comment created by flack:

Yes, I listen to onFlush and then iterate over the insertion/update/deletion arrays

EDIT: Just found out that the entity is listed in both entityInsertions and in entityUpdates. So I guess that explains the missing identity.

@doctrinebot commented on GitHub (Jun 10, 2014): Comment created by flack: Yes, I listen to onFlush and then iterate over the insertion/update/deletion arrays EDIT: Just found out that the entity is listed in both entityInsertions and in entityUpdates. So I guess that explains the missing identity.

admin commented

2026-01-22 14:31:27 +01:00

@doctrinebot commented on GitHub (Jun 10, 2014):

Comment created by flack:

I've debugged a bit further, and it seems like the following is happening:

    public function onFlush(OnFlushEventArgs $args)
    {
        $em = $args->getEntityManager();
        $uow = $em->getUnitOfWork();

        foreach ($uow->getScheduledEntityInsertions() as $entity)
        {
            $entity->changeSomeProperty(time());
            $cm = $em->getClassMetadata(get_class($entity));
            $em->getUnitOfWork()->recomputeSingleEntityChangeSet($cm, $entity); //<== This adds the entity to $entityUpdates
        }
        // Now, the entity from above will show up here, too, and without any identity, since it has not been flushed yet
        foreach ($uow->getScheduledEntityUpdates() as $entity)
        {
              //if I use entity's identity here, it'll be null
        } 
}

If I remove the recomputeSingleEntityChangeSet call here, the changes I made in the listener won't get persisted. But if I get the list of scheduled updates before iterating over the insertions, then any other changes made to different entities won't get persisted. Maybe UnitOfWork should simply check whether the $entity is already in entityInsertions before adding it to entityUpdates?

@doctrinebot commented on GitHub (Jun 10, 2014): Comment created by flack: I've debugged a bit further, and it seems like the following is happening: ``` public function onFlush(OnFlushEventArgs $args) { $em = $args->getEntityManager(); $uow = $em->getUnitOfWork(); foreach ($uow->getScheduledEntityInsertions() as $entity) { $entity->changeSomeProperty(time()); $cm = $em->getClassMetadata(get_class($entity)); $em->getUnitOfWork()->recomputeSingleEntityChangeSet($cm, $entity); //<== This adds the entity to $entityUpdates } // Now, the entity from above will show up here, too, and without any identity, since it has not been flushed yet foreach ($uow->getScheduledEntityUpdates() as $entity) { //if I use entity's identity here, it'll be null } } ``` If I remove the recomputeSingleEntityChangeSet call here, the changes I made in the listener won't get persisted. But if I get the list of scheduled updates before iterating over the insertions, then any other changes made to different entities won't get persisted. Maybe UnitOfWork should simply check whether the $entity is already in entityInsertions before adding it to entityUpdates?

admin commented

2026-01-22 14:31:27 +01:00

@doctrinebot commented on GitHub (Jun 25, 2014):

Comment created by Jeka:

We have the same problem.
After upgrade to 2.4.3 several extensions of DoctrineExtensions don't work.
Is that a bug in doctrine?

@doctrinebot commented on GitHub (Jun 25, 2014): Comment created by Jeka: We have the same problem. After upgrade to 2.4.3 several extensions of DoctrineExtensions don't work. Is that a bug in doctrine?

admin commented

2026-01-22 14:31:27 +01:00

@doctrinebot commented on GitHub (Jun 25, 2014):

Comment created by stof:

I thnk we should find a way to fix the BC break we introduced in 2.4.3. This is quite bad.
Having the same entity in entityInsertions and entityUpdates looks weird anyway, as it is not an update

@doctrinebot commented on GitHub (Jun 25, 2014): Comment created by stof: I thnk we should find a way to fix the BC break we introduced in 2.4.3. This is quite bad. Having the same entity in `entityInsertions` and `entityUpdates` looks weird anyway, as it is not an update

admin commented

2026-01-22 14:31:28 +01:00

@doctrinebot commented on GitHub (Jun 25, 2014):

Comment created by flack:

BTW: I made a unit test for this:

https://github.com/doctrine/doctrine2/pull/1057

@doctrinebot commented on GitHub (Jun 25, 2014): Comment created by flack: BTW: I made a unit test for this: https://github.com/doctrine/doctrine2/pull/1057

admin commented

2026-01-22 14:31:28 +01:00

@doctrinebot commented on GitHub (Jun 26, 2014):

Comment created by zimmermanj42:

I agree with [~stof], it seems odd that an entity would be both scheduled for insertion AND update. But, I don't know too much of the Doctrine internals to say for sure.

I have added a pull request with what seems to work for this. As far as I can tell it passes Doctrine tests and also passes tests for the Tree features in the DoctrineExtensions project (which the DDC-2996 fix broke many portions of).

[https://github.com/doctrine/doctrine2/pull/1074]

@doctrinebot commented on GitHub (Jun 26, 2014): Comment created by zimmermanj42: I agree with [~stof], it seems odd that an entity would be both scheduled for insertion AND update. But, I don't know too much of the Doctrine internals to say for sure. I have added a pull request with what seems to work for this. As far as I can tell it passes Doctrine tests and also passes tests for the Tree features in the DoctrineExtensions project (which the [DDC-2996](http://www.doctrine-project.org/jira/browse/DDC-2996) fix broke many portions of). [https://github.com/doctrine/doctrine2/pull/1074]

admin commented

2026-01-22 14:31:29 +01:00

@doctrinebot commented on GitHub (Jul 6, 2014):

Comment created by @doctrinebot:

A related Github Pull-Request [GH-1057] was closed:
https://github.com/doctrine/doctrine2/pull/1057

@doctrinebot commented on GitHub (Jul 6, 2014): Comment created by @doctrinebot: A related Github Pull-Request [GH-1057] was closed: https://github.com/doctrine/doctrine2/pull/1057

admin commented

2026-01-22 14:31:29 +01:00

@doctrinebot commented on GitHub (Jul 6, 2014):

Comment created by @doctrinebot:

A related Github Pull-Request [GH-1074] was closed:
https://github.com/doctrine/doctrine2/pull/1074

@doctrinebot commented on GitHub (Jul 6, 2014): Comment created by @doctrinebot: A related Github Pull-Request [GH-1074] was closed: https://github.com/doctrine/doctrine2/pull/1074

admin commented

2026-01-22 14:31:29 +01:00

@doctrinebot commented on GitHub (Jul 6, 2014):

Comment created by @ocramius:

Merged at a8035f25a2 - PR at https://github.com/doctrine/doctrine2/pull/1074

@doctrinebot commented on GitHub (Jul 6, 2014): Comment created by @ocramius: Merged at https://github.com/doctrine/doctrine2/commit/a8035f25a218b5a522fa5fc76e0ce8bef4912f0d - PR at https://github.com/doctrine/doctrine2/pull/1074

admin commented

2026-01-22 14:31:30 +01:00

@doctrinebot commented on GitHub (Jul 6, 2014):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Jul 6, 2014): Issue was closed with resolution "Fixed"

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