[PR #1022] [CLOSED] Added EndFlush event #9042

New Issue

admin · 2026-01-22T16:02:57+01:00

admin commented

2026-01-22 16:02:57 +01:00

📋 Pull Request Information

Original PR: https://github.com/doctrine/orm/pull/1022
Author: @dantleech
Created: 4/29/2014
Status: ❌ Closed

Base: master ← Head: end_flush

📝 Commits (1)

e85c50d Added EndFlush event

📊 Changes

5 files changed (+113 additions, -4 deletions)

View changed files

📝 docs/en/reference/events.rst (+31 -3)
➕ lib/Doctrine/ORM/Event/EndFlushEventArgs.php (+31 -0)
📝 lib/Doctrine/ORM/Events.php (+8 -0)
📝 lib/Doctrine/ORM/UnitOfWork.php (+19 -0)
📝 tests/Doctrine/Tests/ORM/Functional/FlushEventTest.php (+24 -1)

📄 Description

This was mentioned on Twitter, this is just a POC to further the discussion.

Updated 10-05-2014

The flush terminate event would be fired after the flush has finished only when there are pending changes.

My primary use case is to enable enitities to be persisted recursively after the initial flush.

The existing endFlush event is fired before the UOW is cleaned up, i.e. whilst the UOW is still dirty.

Use cases

Recursively persisting documents

Example problem

For example, we flush an Article entity.

There is a listener which must create a Route entity automatically
for the Article entity.
There is a listener which must create a Version entity for each Route.

In the first listener would listen to the onFlush event, check the changesets for any Article
enitities, create a new Route entity and recompute the changeset. The new Route entity would
then be committed in one flush.

There is however no sensible way to implement the second listener - if we were to
implement it in onFlush we would have to be sure that the listener was called after the first listener.

This "order of precendence" problem doesn't scale.

With the `terminateFlush` event.

The Article entity would be persisted
User calls flush()
An RouteEventSubscriber subscriber listens to the onFlush event and tracks any Route objects which are due to be persisted.
The UOW completes the transaction, and the flush has finished.
The flushTerminate event would be fired
The RouteEventSubscriber checks to see if any Route objects have been persisted, if so it creates a new Route object, perists
it, and calls flush again.

The same process now take place with a VersionEventSubscriber.

So in summary, when an Article is comitted, 3 flushes take place and three enitities are persisted.

Transactions

I think that any additional flushes should not be part of the same transaction.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/doctrine/orm/pull/1022 **Author:** [@dantleech](https://github.com/dantleech) **Created:** 4/29/2014 **Status:** ❌ Closed **Base:** `master` ← **Head:** `end_flush` --- ### 📝 Commits (1) - [`e85c50d`](https://github.com/doctrine/orm/commit/e85c50d3567bdcc4a035d476f6bb95f74e9e2f78) Added EndFlush event ### 📊 Changes **5 files changed** (+113 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `docs/en/reference/events.rst` (+31 -3) ➕ `lib/Doctrine/ORM/Event/EndFlushEventArgs.php` (+31 -0) 📝 `lib/Doctrine/ORM/Events.php` (+8 -0) 📝 `lib/Doctrine/ORM/UnitOfWork.php` (+19 -0) 📝 `tests/Doctrine/Tests/ORM/Functional/FlushEventTest.php` (+24 -1) </details> ### 📄 Description This was mentioned on Twitter, this is just a POC to further the discussion. **Updated 10-05-2014** The flush terminate event would be fired _after_ the flush has finished _only_ when there are pending changes. My primary use case is to enable enitities to be persisted recursively after the initial flush. The existing `endFlush` event is fired before the UOW is cleaned up, i.e. whilst the UOW is still dirty. ### Use cases - Recursively persisting documents ### Example problem For example, we flush an `Article` entity. - There is a listener which must create a `Route` entity automatically for the `Article` entity. - There is a listener which must create a `Version` entity for each `Route`. In the first listener would listen to the `onFlush` event, check the changesets for any `Article` enitities, create a new `Route` entity and recompute the changeset. The new `Route` entity would then be committed in one flush. There is however no sensible way to implement the second listener - if we were to implement it in `onFlush` we would have to be sure that the listener was called _after_ the first listener. This "order of precendence" problem doesn't scale. ### With the `terminateFlush` event. - The `Article` entity would be persisted - User calls `flush()` - An `RouteEventSubscriber` subscriber listens to the `onFlush` event and tracks any `Route` objects which are due to be persisted. - The UOW completes the transaction, and the flush has finished. - The `flushTerminate` event would be fired - The `RouteEventSubscriber` checks to see if any `Route` objects have been persisted, if so it creates a new `Route` object, perists it, and calls flush again. The same process now take place with a `VersionEventSubscriber`. So in summary, when an Article is comitted, 3 flushes take place and three enitities are persisted. ### Transactions I think that any additional flushes should _not_ be part of the same transaction. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

admin added the pull-request label 2026-01-22 16:02:57 +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#9042

[PR #1022] [CLOSED] Added EndFlush event #9042