I use "notify" as the change tracking policy. If a property of an entity is
changed after it has already been removed from the unit of work, then on
the next flush the entity gets an update first before being deleted finally.
For example, the following code
$em = $this->getDoctrine()->getManager();
$entity = $this->getDoctrine()->getRepository('MyBundle:Entity')->find( 42
);
$em->remove( $entity );
$entity->setFoo( 4711 );
$em->flush();
results into these database commands
START TRANSACTION;
UPDATE entity SET foo = 4711 WHERE id = 42;
DELETE FROM entity WHERE id = 42;
COMMIT;
Is this intended behaviour? In the harmless case the update command is just
needless. But in some cases this results into a failing database
transaction, if the updated value of the property is illegal although
everything would be just fine eventually because the entity is deleted
anyway. (The reason is that PostgreSQL cannot defer NOT NULL and CHECK
constraints to the end of a transaction.) Hence, the unpleasant result
looks like
START TRANSACTION;
UPDATE entity SET foo = 4711 WHERE id = 42;
>> ERROR: Failed CHECK CONSTRAINT on column foo ....
I would never have noted this needless update if I had not got the above
error.
In my humble opinion Doctrine should recognize that the entity is going to
be deleted anyway and skip all prior update commands. Please note, that
this only seems to happen with change tracking policy "notify", with the
default policy "deferred implicit" everything ist just fine.
--
You received this message because you are subscribed to the Google Groups
"doctrine-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/doctrine-user.
For more options, visit https://groups.google.com/d/optout.
