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 'updatedat' 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 updated*at field remains accurate.
Could it not be that the test use both the === operator and in the case of objects either splobjecthash 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.
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
Issue was closed with resolution "Invalid"
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.
granted it seems the splobjecthash 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)...
[~gnat] we still don't have value object support so far
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?
If the object hash changed, then that's expected