mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
DDC-2686: Object changeset computing #3364
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @doctrinebot on GitHub (Sep 17, 2013).
Originally assigned to: @Ocramius on GitHub.
Jira issue originally created by user gnat:
So it seems that when doctrine computes a changeset it uses
($oldObject === $newObject)
which is only true if both objects are the same instance. This fails for objects that have DateTime objects, or even other trivial custom types.
In a post regarding entities with specifically DateTime objects. The reporter noticed that something like $entity->getStartDate()->modify("+ 1day"); fails that test. Alternatively it just plain fails regardless of whether it was updated at all. So in my case I have an object with start/end fields who are always 'updated' via forms regardless of whether I changed anything. This causes the 'updated_at' field to always be updated regardless of whether the object actually changed or not. I have to implement a listener that watches these changes and then does additional comparisons to see if it actually_ changed... and then exclude it so my updatedat field remains accurate.
Could it not be that the test use both the === operator and in the case of objects either spl_object_hash or alternatively using annotations provide some form of comparison function to use??
This also affects anyone using custom types to handle 'enum' types and the like. Since those objects won't ever be the same instance.
This is both an 'accuracy' issue and a 'performance' issue as it causes useless SQL updates for any object that has a DateTime object or a custom type.
@doctrinebot commented on GitHub (Sep 17, 2013):
Comment created by @ocramius:
Please see http://stackoverflow.com/questions/15486402/doctrine2-orm-does-not-save-changes-to-a-datetime-field/15488230
DateTime fields are not compared by-val. Same applies to any object type
@doctrinebot commented on GitHub (Sep 17, 2013):
Issue was closed with resolution "Invalid"
@doctrinebot commented on GitHub (Sep 17, 2013):
Comment created by gnat:
So you guys are wicked quick with your answers... I changed the description after I cloned a previous bug... It still seems like something that needs changing to me.
@doctrinebot commented on GitHub (Sep 17, 2013):
Comment created by gnat:
granted it seems the spl_object_hash function won't return the same hash for separate objects anyway - it still seems that there needs to be some added change computing in there for the case mentioned above (excessive updates and knowing that an object actually changed)...
@doctrinebot commented on GitHub (Sep 17, 2013):
Comment created by @ocramius:
[~gnat] we still don't have value object support so far
@doctrinebot commented on GitHub (Sep 18, 2013):
Comment created by gnat:
So perhaps you don't have object value comparison. I have one object with an integer field. It is being marked as changed when the changeset shows that both before and after the value is 0 is that normal?
@doctrinebot commented on GitHub (Sep 18, 2013):
Comment created by @ocramius:
If the object hash changed, then that's expected