Type: New Feature
Affects Version/s: Git Master, 2.3.4
Fix Version/s: None
Security Level: All
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 updated_at 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.