Uploaded image for project: 'Doctrine 2 - ORM'
  1. Doctrine 2 - ORM
  2. DDC-113

Cascaded persist avoids LifecycleCallbacks

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0-ALPHA3
    • Fix Version/s: 2.0-ALPHA4
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None

      Description

      When an Entity is created by 'cascade=

      {"persist"}

      ', its LifecycleCallbacks (e.g. "PrePersist"!) are not invoked.

      When it is persisted explicitly, everything workes fine and the events are called...

        Activity

        nicokaiser Nico Kaiser created issue -
        romanb Roman S. Borschel made changes -
        Field Original Value New Value
        Priority Major [ 3 ] Critical [ 2 ]
        romanb Roman S. Borschel made changes -
        Affects Version/s 2.0-ALPHA3 [ 10029 ]
        Fix Version/s 2.0-ALPHA4 [ 10036 ]
        romanb Roman S. Borschel made changes -
        Assignee Roman S. Borschel [ romanb ] Benjamin Eberlei [ beberlei ]
        Hide
        beberlei Benjamin Eberlei added a comment -

        Works for me on trunk, added test-case that proves it (Doctrine\Tests\ORM\Functional\LifecycleCallbackTest::testCascadedEntitiesCallsPrePersist())

        Show
        beberlei Benjamin Eberlei added a comment - Works for me on trunk, added test-case that proves it (Doctrine\Tests\ORM\Functional\LifecycleCallbackTest::testCascadedEntitiesCallsPrePersist())
        beberlei Benjamin Eberlei made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 2.0-ALPHA4 [ 10036 ]
        Resolution Cannot Reproduce [ 5 ]
        Hide
        nicokaiser Nico Kaiser added a comment -

        There is still an issue. You can reproduce it if you change the test case slightly to this:

            /**
             * @group DDC-113
             */
            public function testCascadedEntitiesCallsPrePersist()
            {
                $e1 = new LifecycleCallbackTestEntity;
                $e2 = new LifecycleCallbackTestEntity;
        
                $c = new LifecycleCallbackCascader();
                
                $this->_em->persist($c);
                
                $c->entities[] = $e1;
                $c->entities[] = $e2;
        
                //$this->_em->persist($c);
                $this->_em->flush();
        
                $this->assertTrue($e1->prePersistCallbackInvoked);
                $this->assertTrue($e2->prePersistCallbackInvoked);
            }
        

        The difference to the existing (and indeed working) test case is that the Cascader entity is persisted before the collection entries are added.

        Show
        nicokaiser Nico Kaiser added a comment - There is still an issue. You can reproduce it if you change the test case slightly to this: /** * @group DDC-113 */ public function testCascadedEntitiesCallsPrePersist() { $e1 = new LifecycleCallbackTestEntity; $e2 = new LifecycleCallbackTestEntity; $c = new LifecycleCallbackCascader(); $this->_em->persist($c); $c->entities[] = $e1; $c->entities[] = $e2; //$this->_em->persist($c); $this->_em->flush(); $this->assertTrue($e1->prePersistCallbackInvoked); $this->assertTrue($e2->prePersistCallbackInvoked); } The difference to the existing (and indeed working) test case is that the Cascader entity is persisted before the collection entries are added.
        nicokaiser Nico Kaiser made changes -
        Resolution Cannot Reproduce [ 5 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Hide
        beberlei Benjamin Eberlei added a comment - - edited

        That is valid behaviour according to the lifecycle of an entity, persist gets cascaded right and only when ->persist() is called.

        In the case you show, the two entities are also not persisted, because the cascade was already executed.

        Show
        beberlei Benjamin Eberlei added a comment - - edited That is valid behaviour according to the lifecycle of an entity, persist gets cascaded right and only when ->persist() is called. In the case you show, the two entities are also not persisted, because the cascade was already executed.
        Hide
        nicokaiser Nico Kaiser added a comment -

        From a technical point of view this is ok - but from an intuitive point of view I would think I can use persist whereever I want. So I can create an entity, persist it (so it gets written to the DB), make changes to it (like adding entities to its collection) and getting its saved (and the collection entities persisted) when I call flush().

        So I suspect lifecycle events to be called whenever an entity is persisted. And in this case LifecycleCallbackTestEntity's are persisted automatically by flush() (and this is after the Cascader is persisted!), so lifecycle events should fire here.

        Show
        nicokaiser Nico Kaiser added a comment - From a technical point of view this is ok - but from an intuitive point of view I would think I can use persist whereever I want. So I can create an entity, persist it (so it gets written to the DB), make changes to it (like adding entities to its collection) and getting its saved (and the collection entities persisted) when I call flush(). So I suspect lifecycle events to be called whenever an entity is persisted. And in this case LifecycleCallbackTestEntity's are persisted automatically by flush() (and this is after the Cascader is persisted!), so lifecycle events should fire here.
        romanb Roman S. Borschel made changes -
        Assignee Benjamin Eberlei [ beberlei ] Roman S. Borschel [ romanb ]
        romanb Roman S. Borschel made changes -
        Status Reopened [ 4 ] In Progress [ 3 ]
        Hide
        romanb Roman S. Borschel added a comment -

        I have a fix for this ready, however, I want to look into something else before committing. I'll address this over the weekend.

        Show
        romanb Roman S. Borschel added a comment - I have a fix for this ready, however, I want to look into something else before committing. I'll address this over the weekend.
        Hide
        romanb Roman S. Borschel added a comment -

        Should be fixed now.

        Show
        romanb Roman S. Borschel added a comment - Should be fixed now.
        romanb Roman S. Borschel made changes -
        Status In Progress [ 3 ] Closed [ 6 ]
        Fix Version/s 2.0-ALPHA4 [ 10036 ]
        Resolution Fixed [ 1 ]
        beberlei Benjamin Eberlei made changes -
        Workflow jira [ 10332 ] jira-feedback [ 15464 ]
        beberlei Benjamin Eberlei made changes -
        Workflow jira-feedback [ 15464 ] jira-feedback2 [ 17328 ]
        beberlei Benjamin Eberlei made changes -
        Workflow jira-feedback2 [ 17328 ] jira-feedback3 [ 19585 ]

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

          People

          • Assignee:
            romanb Roman S. Borschel
            Reporter:
            nicokaiser Nico Kaiser
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: