Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-1507

State change detection for version incrementation (for optimistic locking) in combination with orphanRemoval

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.1.4, 2.4.7
    • Fix Version/s: None
    • Component/s: ORM
    • Security Level: All

      Description

      As i understand the documentation correctly, orphanRemoval associations have the meaning of a "part of" relationship. In the example (http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-associations.html#orphan-removal) the adresses are part of the contact.

      In my opinion we should reason that the state of the adress consists of the states of all nested contacts. As a consequence we should flag the contact as "dirty" when the adresses change.

      This is relevant for optimistic locking scenarios or event handlers. In my application i tried to use optimistic locking for "contacts", which does not work if i don't change anything in the contact but only in the nested addresses.

        Issue Links

          Activity

          Georg Wächter created issue -
          Georg Wächter made changes -
          Field Original Value New Value
          Affects Version/s 2.1.4 [ 10165 ]
          Affects Version/s 2.1.3 [ 10164 ]
          Issue Type Improvement [ 4 ] Bug [ 1 ]
          Hide
          Benjamin Eberlei added a comment -

          This is still only an approvement, you can workaround this and handle is in your domain code.

          Show
          Benjamin Eberlei added a comment - This is still only an approvement, you can workaround this and handle is in your domain code.
          Benjamin Eberlei made changes -
          Issue Type Bug [ 1 ] Improvement [ 4 ]
          Hide
          Georg Wächter added a comment -

          Not in all cases. The first problem is that my domain code can't modify the version property, doctrine seems to block any manipulations to it. So i'm not able to increment the variable myself.

          The only solution is to implement optimistic locking on my own or to add a dummy persistent boolean field that gets inversed by my domain code .. which would trigger the doctrine implementation for the optimistic locking.

          I think it's clear that the second option shouldn't be a choice. If doctrine doesn't handle the overall case exactly it should allow me to increment the version number myself.

          Show
          Georg Wächter added a comment - Not in all cases. The first problem is that my domain code can't modify the version property, doctrine seems to block any manipulations to it. So i'm not able to increment the variable myself. The only solution is to implement optimistic locking on my own or to add a dummy persistent boolean field that gets inversed by my domain code .. which would trigger the doctrine implementation for the optimistic locking. I think it's clear that the second option shouldn't be a choice. If doctrine doesn't handle the overall case exactly it should allow me to increment the version number myself.
          Benjamin Eberlei made changes -
          Workflow jira [ 13212 ] jira-feedback [ 13992 ]
          Benjamin Eberlei made changes -
          Workflow jira-feedback [ 13992 ] jira-feedback2 [ 15856 ]
          Benjamin Eberlei made changes -
          Workflow jira-feedback2 [ 15856 ] jira-feedback3 [ 18112 ]
          Hide
          Darien Hager added a comment -

          Bump: I'm having a similar issue. Essentially I want to force the entity's version to be updated, even if there aren't any other "real" changes to go with it.

          One idea for a workaround: Since version fields can only be integers or timestamps, define a "clearly wrong" magic value like "FORCE_INCREMENT". This would allow objects to signal without needing a reference to the EntityManager.

          Would folks be open to a pull-request over this?

          Show
          Darien Hager added a comment - Bump: I'm having a similar issue. Essentially I want to force the entity's version to be updated, even if there aren't any other "real" changes to go with it. One idea for a workaround: Since version fields can only be integers or timestamps, define a "clearly wrong" magic value like "FORCE_INCREMENT". This would allow objects to signal without needing a reference to the EntityManager. Would folks be open to a pull-request over this?
          Darien Hager made changes -
          Affects Version/s 2.4.7 [ 10724 ]
          Darien Hager made changes -
          Labels unitofwork versioned
          Darien Hager made changes -
          Link This issue is referenced by DDC-2864 [ DDC-2864 ]
          Darien Hager made changes -
          Link This issue is referenced by DDC-3640 [ DDC-3640 ]

          This list may be incomplete, as errors occurred whilst retrieving source from linked applications:

          • Request to http://www.doctrine-project.org/fisheye/ failed: Error in remote call to 'FishEye 0 (http://www.doctrine-project.org/fisheye/)' (http://www.doctrine-project.org/fisheye) [AbstractRestCommand{path='/rest-service-fe/search-v1/crossRepositoryQuery', params={query=DDC-1507, expand=changesets[0:20].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)

            People

            • Assignee:
              Benjamin Eberlei
              Reporter:
              Georg Wächter
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: