Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-1879

Orphans are neither nulled nor removed when merging a graph of detached entities

    Details

    • Type: Bug Bug
    • Status: Awaiting Feedback
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.2
    • Fix Version/s: None
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None
    • Environment:
      Doctrine 2.2.2
      PHP 5.3.10 with Suhosin-Patch
      mysql Ver 14.14 Distrib 5.5.15, for osx10.7
      Mac OS X 10.7 Lion

      Description

      When merging a graph of detached entities, the created entitied are created and the updated entities are updated but the non-present entities (which exist in the database but are not in the graph) are neither removed nor have them their association column nullified.

      Example :

      In my code I have 2 entities : Parent and Child. There is a OneToMany(cascade=

      {"all"}

      , orphanRemoval=true) relation defined in Parent.

      In my database I have a Parent row with an id of 1, which has 3 Children with ids 1,2,3.

      When I write the following code, I expect the Parent with id 1 and the Child with id 2 to be updated, a new Child to be created and the Child with id 1 and 3 to be deleted.

      $parent = new Parent(); $parent->id = 1  // detached entity
      $existing_child = new Child(); $child->id = 2 // detached entity
      $new_child = new Child(); // new entity
      $dinner->addChild($existing_child);
      $dinner->addChild($new_child);
      
      $em->merge($dinner);
      
      $em->flush();
      

      The objects I expect to be created and updated have the correct behaviour but the old children are not touched, they are still present in the database.

        Activity

        Philippe Van Eerdenbrugghe created issue -
        Benjamin Eberlei made changes -
        Field Original Value New Value
        Workflow jira [ 13784 ] jira-feedback [ 14080 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback [ 14080 ] jira-feedback2 [ 15944 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback2 [ 15944 ] jira-feedback3 [ 18192 ]
        Marco Pivetta made changes -
        Description When merging a graph of detached entities, the created entitied are created and the updated entities are updated but the non-present entities (which exist in the database but are not in the graph) are neither removed nor have them their association column nullified.

        Example :

        In my code I have 2 entities : Parent and Child. There is a OneToMany(cascade={"all"}, orphanRemoval=true) relation defined in Parent.

        In my database I have a Parent row with an id of 1, which has 3 Children with ids 1,2,3.

        When I write the following code, I expect the Parent with id 1 and the Child with id 2 to be updated, a new Child to be created and the Child with id 1 and 3 to be deleted.
        {quote}
        $parent = new Parent(); $parent->id = 1 // detached entity
        $existing_child = new Child(); $child->id = 2 // detached entity
        $new_child = new Child(); // new entity
        $dinner->addChild($existing_child);
        $dinner->addChild($new_child);

        $em->merge($dinner);

        $em->flush();
        {quote}

        The objects I expect to be created and updated have the correct behaviour but the old children are not touched, they are still present in the database.
        When merging a graph of detached entities, the created entitied are created and the updated entities are updated but the non-present entities (which exist in the database but are not in the graph) are neither removed nor have them their association column nullified.

        Example :

        In my code I have 2 entities : Parent and Child. There is a OneToMany(cascade={"all"}, orphanRemoval=true) relation defined in Parent.

        In my database I have a Parent row with an id of 1, which has 3 Children with ids 1,2,3.

        When I write the following code, I expect the Parent with id 1 and the Child with id 2 to be updated, a new Child to be created and the Child with id 1 and 3 to be deleted.
        {code}
        $parent = new Parent(); $parent->id = 1 // detached entity
        $existing_child = new Child(); $child->id = 2 // detached entity
        $new_child = new Child(); // new entity
        $dinner->addChild($existing_child);
        $dinner->addChild($new_child);

        $em->merge($dinner);

        $em->flush();
        {code}

        The objects I expect to be created and updated have the correct behaviour but the old children are not touched, they are still present in the database.
        Marco Pivetta made changes -
        Comment [ [~systho] can you provide the code before following? {code}$parent = new Parent();{code}
        Or can you fix the example so that it is clear if the detached entities actually have an identifier? ]
        Hide
        Marco Pivetta added a comment -

        I don't think this is valid. Orphan removal scheduling is handled only when an unit of work is available.

        What's the state of `$dinner` before your example? Can you `var_dump` it?

        Show
        Marco Pivetta added a comment - I don't think this is valid. Orphan removal scheduling is handled only when an unit of work is available. What's the state of `$dinner` before your example? Can you `var_dump` it?
        Marco Pivetta made changes -
        Status Open [ 1 ] Awaiting Feedback [ 10000 ]

        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-1879, expand=changesets[0:20].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Philippe Van Eerdenbrugghe
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: