Cannot persist an entity during onFlush #7491

New Issue

admin · 2026-01-22T15:52:16+01:00

admin commented

2026-01-22 15:52:16 +01:00

Originally created by @yann-eugone on GitHub (Mar 27, 2025).

Bug Report

Q	A
Version	3.3.2
Previous Version if the bug is a regression

Summary

Not able to persist a new entity in the onFlush listener.

Current behavior

When using EntityManager::persist() along with UnitOfWork::computeChangeSet(), I get a SQL syntax error: the insert query does not have any parameter bound.

When using Collection::add() along with UnitOfWork::recomputeSingleEntityChangeSet(), nothing happens: the entity is never saved.

Expected behavior

Regarding the documentation, we should be able to persist new entities, on their own, or using collections:

The following restrictions apply to the onFlush event:

If you create and persist a new entity in onFlush, then calling EntityManager::persist() is not enough. You have to execute an additional call to $unitOfWork->computeChangeSet($classMetadata, $entity).

Changing primitive fields or associations requires you to explicitly trigger a re-computation of the changeset of the affected entity. This can be done by calling $unitOfWork->recomputeSingleEntityChangeSet($classMetadata, $entity).

How to reproduce

I created a pretty simple project with my use case
https://github.com/yann-eugone/doctrine-persist-in-onflush

The idea is that I have a AuditEvent entity that should be created every time an entity is updated.

Originally created by @yann-eugone on GitHub (Mar 27, 2025). ### Bug Report | Q | A |-------------------------------------------- | ------ | Version | 3.3.2 | Previous Version if the bug is a regression | #### Summary Not able to persist a new entity in the `onFlush` listener. #### Current behavior When using `EntityManager::persist()` along with `UnitOfWork::computeChangeSet()`, I get a `SQL syntax error`: the insert query does not have any parameter bound. When using `Collection::add()` along with `UnitOfWork::recomputeSingleEntityChangeSet()`, nothing happens: the entity is never saved. #### Expected behavior Regarding [the documentation](https://www.doctrine-project.org/projects/doctrine-orm/en/3.3/reference/events.html#reference-events-on-flush), we should be able to persist new entities, on their own, or using collections: > The following restrictions apply to the onFlush event: > > - If you create and persist a new entity in onFlush, then calling `EntityManager::persist()` is not enough. You have to execute an additional call to `$unitOfWork->computeChangeSet($classMetadata, $entity)`. > - Changing primitive fields or associations requires you to explicitly trigger a re-computation of the changeset of the affected entity. This can be done by calling `$unitOfWork->recomputeSingleEntityChangeSet($classMetadata, $entity)`. #### How to reproduce I created a pretty simple project with my use case https://github.com/yann-eugone/doctrine-persist-in-onflush The idea is that I have a `AuditEvent` entity that should be created every time an entity is updated.

admin closed this issue

2026-01-22 15:52:16 +01:00

admin commented

2026-01-22 15:52:16 +01:00

@mpdude commented on GitHub (Mar 30, 2025):

#10900 is related.

Are you seeing #10869 here?

@mpdude commented on GitHub (Mar 30, 2025): #10900 is related. Are you seeing #10869 here?

admin commented

2026-01-22 15:52:17 +01:00

@yann-eugone commented on GitHub (Mar 31, 2025):

Not sure it is related, not doing any flush during the event listener
Tried to downgrade doctrine/orm on the project, never been able to see it work as expected

@yann-eugone commented on GitHub (Mar 31, 2025): Not sure it is related, not doing any `flush` during the event listener Tried to downgrade `doctrine/orm` on the project, never been able to see it work as expected

admin commented

2026-01-22 15:52:18 +01:00

@yann-eugone commented on GitHub (Apr 1, 2025):

I think I found the reason why it do fails
My model is not that simple I wrote in the description
I do have an AuditEvent entity that represent an update event
But that entity has a collection of to AuditEventRelation entities, that represent payload parts when updated value are entities and not scalar
The exception I get with the persist strategy is when Doctrine try to insert these relations

I had to manually persist these relations to in order to make it work

foreach ($event->getRelations() as $relation) {
    $entityManager->persist($relation);
    $unitOfWork->computeChangeSet($eventRelationMetadata, $relation);
}

5dac0ce503

I still have no idea how to fix the record strategy

@yann-eugone commented on GitHub (Apr 1, 2025): I think I found the reason why it do fails My model is not that simple I wrote in the description I do have an `AuditEvent` entity that represent an update event But that entity has a collection of to `AuditEventRelation` entities, that represent payload parts when updated value are entities and not scalar The exception I get with the `persist` strategy is when Doctrine try to insert these relations I had to manually persist these relations to in order to make it work ```php foreach ($event->getRelations() as $relation) { $entityManager->persist($relation); $unitOfWork->computeChangeSet($eventRelationMetadata, $relation); } ``` https://github.com/yann-eugone/doctrine-persist-in-onflush/commit/5dac0ce5030dc417a46b83e7ce93c4d6cb954979 I still have no idea how to fix the `record` strategy

admin commented

2026-01-22 15:52:18 +01:00

@yann-eugone commented on GitHub (Apr 2, 2025):

I believe I've found a solution to the problem I've faced
You can close it if you want

Is still believe that the error was very unclear

@yann-eugone commented on GitHub (Apr 2, 2025): I believe I've found **a** solution to the problem I've faced You can close it if you want Is still believe that the error was very unclear

admin referenced this issue

2026-01-22 16:07:48 +01:00

[PR #7491] Remove dead code #10514

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#7491