Skip to content

Loading…

DDC-2686: Object changeset computing #3425

Closed
doctrinebot opened this Issue · 7 comments

2 participants

@doctrinebot

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.

@doctrinebot

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

Issue was closed with resolution "Invalid"

@doctrinebot

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

Comment created by gnat:

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

@doctrinebot

Comment created by @ocramius:

[~gnat] we still don't have value object support so far

@doctrinebot

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

Comment created by @ocramius:

If the object hash changed, then that's expected

@Ocramius Ocramius was assigned by doctrinebot
@doctrinebot doctrinebot closed this
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.