DDC-113: Cascaded persist avoids LifecycleCallbacks #144

New Issue

admin · 2026-01-22T12:28:28+01:00

admin commented

2026-01-22 12:28:28 +01:00

Originally created by @doctrinebot on GitHub (Nov 4, 2009).

Jira issue originally created by user nicokaiser:

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

Originally created by @doctrinebot on GitHub (Nov 4, 2009). Jira issue originally created by user nicokaiser: 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...

admin added the Bug label 2026-01-22 12:28:28 +01:00

admin closed this issue

2026-01-22 12:28:29 +01:00

admin commented

2026-01-22 12:28:30 +01:00

@doctrinebot commented on GitHub (Dec 11, 2009):

Comment created by @beberlei:

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

@doctrinebot commented on GitHub (Dec 11, 2009): Comment created by @beberlei: Works for me on trunk, added test-case that proves it (Doctrine\Tests\ORM\Functional\LifecycleCallbackTest::testCascadedEntitiesCallsPrePersist())

admin commented

2026-01-22 12:28:31 +01:00

@doctrinebot commented on GitHub (Dec 14, 2009):

Comment created by nicokaiser:

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

    /****
     * @group [DDC-113](http://www.doctrine-project.org/jira/browse/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.

@doctrinebot commented on GitHub (Dec 14, 2009): Comment created by nicokaiser: There is still an issue. You can reproduce it if you change the test case slightly to this: ``` /**** * @group [DDC-113](http://www.doctrine-project.org/jira/browse/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.

admin commented

2026-01-22 12:28:31 +01:00

@doctrinebot commented on GitHub (Dec 14, 2009):

Comment created by @beberlei:

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.

@doctrinebot commented on GitHub (Dec 14, 2009): Comment created by @beberlei: 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.

admin commented

2026-01-22 12:28:31 +01:00

@doctrinebot commented on GitHub (Dec 14, 2009):

Comment created by nicokaiser:

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.

@doctrinebot commented on GitHub (Dec 14, 2009): Comment created by nicokaiser: 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.

admin commented

2026-01-22 12:28:32 +01:00

@doctrinebot commented on GitHub (Dec 17, 2009):

Comment created by romanb:

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

@doctrinebot commented on GitHub (Dec 17, 2009): Comment created by romanb: I have a fix for this ready, however, I want to look into something else before committing. I'll address this over the weekend.

admin commented

2026-01-22 12:28:32 +01:00

@doctrinebot commented on GitHub (Dec 18, 2009):

Comment created by romanb:

Should be fixed now.

@doctrinebot commented on GitHub (Dec 18, 2009): Comment created by romanb: Should be fixed now.

admin commented

2026-01-22 12:28:33 +01:00

@doctrinebot commented on GitHub (Dec 18, 2009):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Dec 18, 2009): Issue was closed with resolution "Fixed"

admin referenced this issue