[PR #11132] Update in-memory collections before dispatching the postRemove event #12807

New Issue

admin · 2026-01-22T16:15:14+01:00

admin commented

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

Original Pull Request: https://github.com/doctrine/orm/pull/11132

State: closed
Merged: No

Make sure in-memory collections have removed entities unset before the postRemove event is dispatched. This is related to #11098, although by itself probably not going to fix the regression.

Background

When an entity is removed from the database, the UoW also takes care of removing that entity from all in-memory collections. #10763 moved this cleanup and taking snapshots of updated collections to a very late stage during the commit phase, in order to avoid other side effects.

Now, part of the issue in #11098 is that postRemove event listeners will be called at a point where the database-level DELETE has happened (although the transaction has not yet been committed), but the in-memory collections have not yet been updated.

Suggested change

This PR moves the code part that unsets removed entities from in-memory collections and takes collection snapshots (makes collections "clean") from after transaction commit to before the postRemove event. That brings the in-memory update closer to the database-level execution.

In the case of a transaction failure/abort, this leaves us with updated and snapshotted in-memory collections, but no database-level updates. But, at this point, probably things got inconsistent anyways, the EM will be closed and we need not be too worried about the state.

On the other hand, it might not be worth the effort to have clean/consistent collections at postRemove time, since that still leaves us with dirty/inconsistent states during postPersist or postUpdate.

**Original Pull Request:** https://github.com/doctrine/orm/pull/11132 **State:** closed **Merged:** No --- Make sure in-memory collections have removed entities unset before the `postRemove` event is dispatched. This is related to #11098, although by itself probably not going to fix the regression. #### Background When an entity is removed from the database, the UoW also takes care of removing that entity from all in-memory collections. #10763 moved this cleanup and taking snapshots of updated collections to a very late stage during the commit phase, in order to avoid other side effects. Now, part of the issue in #11098 is that `postRemove` event listeners will be called at a point where the database-level `DELETE` has happened (although the transaction has not yet been committed), but the in-memory collections have not yet been updated. #### Suggested change This PR moves the code part that unsets removed entities from in-memory collections and takes collection snapshots (makes collections "clean") from after transaction commit to before the `postRemove` event. That brings the in-memory update closer to the database-level execution. In the case of a transaction failure/abort, this leaves us with updated and snapshotted in-memory collections, but no database-level updates. But, at this point, probably things got inconsistent anyways, the EM will be closed and we need not be too worried about the state. On the other hand, it might not be worth the effort to have clean/consistent collections at `postRemove` time, since that still leaves us with dirty/inconsistent states during `postPersist` or `postUpdate`.

admin added the pull-request label 2026-01-22 16:15:14 +01:00

admin closed this issue

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

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

[PR #11132] Update in-memory collections before dispatching the postRemove event #12807

Background

Suggested change

[PR #11132] Update in-memory collections before dispatching the `postRemove` event #12807