Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Invalid
    • Affects Version/s: Git Master, 2.3.4
    • Fix Version/s: None
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Marco Pivetta added a comment -

        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

        Show
        Marco Pivetta added a comment - 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
        Hide
        Nathanael Noblet added a comment -

        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.

        Show
        Nathanael Noblet added a comment - 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.
        Hide
        Nathanael Noblet added a comment -

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

        Show
        Nathanael Noblet added a comment - 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)...
        Hide
        Marco Pivetta added a comment -

        Nathanael Noblet we still don't have value object support so far

        Show
        Marco Pivetta added a comment - Nathanael Noblet we still don't have value object support so far
        Hide
        Nathanael Noblet added a comment -

        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?

        Show
        Nathanael Noblet added a comment - 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?
        Hide
        Marco Pivetta added a comment -

        If the object hash changed, then that's expected

        Show
        Marco Pivetta added a comment - If the object hash changed, then that's expected

          People

          • Assignee:
            Marco Pivetta
            Reporter:
            Nathanael Noblet
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: