postPersist event not fired for scheduled insertions if unity of work also includes scheduled updates #5251

New Issue

admin · 2026-01-22T15:02:38+01:00

admin commented

2026-01-22 15:02:38 +01:00

Originally created by @jwmwalrus on GitHub (Sep 12, 2016).

Hi,

The postPersist event is not invoked for insertions (i.e., new entities), if the set of changes to be flushed includes pre-existing entities being updated. For example, the following does not invoke the postPersist event for the Invoice entity:

public function newAction() {
    // ...
    $em = $this->get('doctrine')->getManager();
    $invoice = new Invoice();
    // ...
    if ($peticion->isMethod('POST')) {
        $form->handleRequest($petition);

        $config = $em->getRepository('AppBundle:Config')->find(1);

        $newinvoicenum = $config->getInvoicenum() + 1;

        $config->setInvoicenum($newinvoicenum);
        $invoice->setInvoicenum($newinvoicenum);
        $em->persist($invoice);
        $em->persist($config);
        $em->flush();

        return new Response($invoice->getId());
    }
    // ...
}

The postPersist event is only invoked by rearranging lines, as in:


public function newAction() {
    // ...
    $em = $this->get('doctrine')->getManager();
    $invoice = new Invoice();
    // ...
    if ($peticion->isMethod('POST')) {
        $form->handleRequest($petition);

        $config = $em->getRepository('AppBundle:Config')->find(1);

        $newinvoicenum = $config->getInvoicenum() + 1;

        $invoice->setInvoicenum($newinvoicenum);
        $em->persist($invoice);
        $em->flush();

        $config->setInvoicenum($newinvoicenum);
        $em->persist($config);
        $em->flush();

        return new Response($invoice->getId());
    }
    // ...
}

It looks to me like a bug ---or at the very least, a limitation, since it forces the developer to flush things in a certain order.

Is that the expected/intented behavior?

Originally created by @jwmwalrus on GitHub (Sep 12, 2016). Hi, The postPersist event is not invoked for insertions (i.e., new entities), if the set of changes to be flushed includes pre-existing entities being updated. For example, the following does not invoke the postPersist event for the Invoice entity: ``` php public function newAction() { // ... $em = $this->get('doctrine')->getManager(); $invoice = new Invoice(); // ... if ($peticion->isMethod('POST')) { $form->handleRequest($petition); $config = $em->getRepository('AppBundle:Config')->find(1); $newinvoicenum = $config->getInvoicenum() + 1; $config->setInvoicenum($newinvoicenum); $invoice->setInvoicenum($newinvoicenum); $em->persist($invoice); $em->persist($config); $em->flush(); return new Response($invoice->getId()); } // ... } ``` The postPersist event is only invoked by rearranging lines, as in: ``` php public function newAction() { // ... $em = $this->get('doctrine')->getManager(); $invoice = new Invoice(); // ... if ($peticion->isMethod('POST')) { $form->handleRequest($petition); $config = $em->getRepository('AppBundle:Config')->find(1); $newinvoicenum = $config->getInvoicenum() + 1; $invoice->setInvoicenum($newinvoicenum); $em->persist($invoice); $em->flush(); $config->setInvoicenum($newinvoicenum); $em->persist($config); $em->flush(); return new Response($invoice->getId()); } // ... } ``` It looks to me like a bug ---or at the very least, a limitation, since it forces the developer to flush things in a certain order. Is that the expected/intented behavior?

admin commented

2026-01-22 15:02:39 +01:00

@jwmwalrus commented on GitHub (Nov 16, 2016):

I apologize in advance if I'm bothering too much, but...

Any comments regarding this issue? Is it a bug, a limitation, a feature?

@jwmwalrus commented on GitHub (Nov 16, 2016): I apologize in advance if I'm bothering too much, but... Any comments regarding this issue? Is it a bug, a limitation, a feature?

admin commented

2026-01-22 15:02:39 +01:00

@lcobucci commented on GitHub (Nov 16, 2016):

@jwmwalrus can you try reproducing it against 05e77868ab/tests/Doctrine/Tests/ORM/Functional/Ticket please? (see that dir for examples)

@lcobucci commented on GitHub (Nov 16, 2016): @jwmwalrus can you try reproducing it against https://github.com/doctrine/doctrine2/tree/05e77868ab07e58518779f19f2f88f5c1411d56d/tests/Doctrine/Tests/ORM/Functional/Ticket please? (see that dir for examples)

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5251