Skip to content

Loading…

DDC-3160: Regression in reComputeSingleEntityChangeset #3940

Closed
doctrinebot opened this Issue · 12 comments

2 participants

@doctrinebot

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

@doctrinebot

Comment created by @ocramius:

Do you have any listeners interacting with your changesets?

@doctrinebot

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

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

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

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

Comment created by flack:

BTW: I made a unit test for this:

#1057

@doctrinebot

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

[#1074]

@doctrinebot

Comment created by @doctrinebot:

A related Github Pull-Request [GH-1057] was closed:
#1057

@doctrinebot

Comment created by @doctrinebot:

A related Github Pull-Request [GH-1074] was closed:
#1074

@doctrinebot

Comment created by @ocramius:

Merged at a8035f2 - PR at #1074

@doctrinebot

Issue was closed with resolution "Fixed"

@Ocramius Ocramius was assigned by doctrinebot
@doctrinebot doctrinebot added this to the 2.5 milestone
@doctrinebot doctrinebot closed this
@doctrinebot doctrinebot added the Bug label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.