DDC-877: Auto Flush pending transactions at destruct time #1088

New Issue

admin · 2026-01-22T13:01:35+01:00

admin commented

2026-01-22 13:01:35 +01:00

Originally created by @doctrinebot on GitHub (Nov 16, 2010).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user nd987:

It would be great if Doctrine would auto flush pending transactions at the end of script execution. This would make the coder's life that much easier, as they don't have to remember to flush() somewhere after they are done making changes...they just call persist() as needed, knowing that if they don't explicitly flush(), it will automatically happen.

Explicitly flush()-ing would still be supported and even encouraged. The Entity Manager's **destruct() function simply has to check for pending transactions, flush()-ing any it finds.

Originally created by @doctrinebot on GitHub (Nov 16, 2010). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user nd987: It would be great if Doctrine would auto flush pending transactions at the end of script execution. This would make the coder's life that much easier, as they don't have to remember to flush() somewhere after they are done making changes...they just call persist() as needed, knowing that if they don't explicitly flush(), it will automatically happen. Explicitly flush()-ing would still be supported and even encouraged. The Entity Manager's **destruct() function simply has to check for pending transactions, flush()-ing any it finds.

admin added the Improvement label 2026-01-22 13:01:35 +01:00

admin closed this issue

2026-01-22 13:01:35 +01:00

admin commented

2026-01-22 13:01:37 +01:00

@doctrinebot commented on GitHub (Nov 16, 2010):

Comment created by @beberlei:

No, the explicitlyness of flush is very important. If you have a read only request with lots of objects flush is going to cost a huge bunch of performance.

@doctrinebot commented on GitHub (Nov 16, 2010): Comment created by @beberlei: No, the explicitlyness of flush is very important. If you have a read only request with lots of objects flush is going to cost a huge bunch of performance.

admin commented

2026-01-22 13:01:39 +01:00

@doctrinebot commented on GitHub (Nov 16, 2010):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Nov 16, 2010): Issue was closed with resolution "Won't Fix"

admin commented

2026-01-22 13:01:39 +01:00

@doctrinebot commented on GitHub (Nov 17, 2010):

Comment created by nd987:

Ah, I had assumed that Doctrine kept track of whether or not anything needed to be flushed, so that calling flush() when no changes had been made was an inexpensive operation and did not loop over every object. In a read only request, persist() would have never been called and hence no flush required...so inside the flush() method, a simple check like needsFlush() could prevent a loop over all objects.

@doctrinebot commented on GitHub (Nov 17, 2010): Comment created by nd987: Ah, I had assumed that Doctrine kept track of whether or not anything needed to be flushed, so that calling flush() when no changes had been made was an inexpensive operation and did not loop over every object. In a read only request, persist() would have never been called and hence no flush required...so inside the flush() method, a simple check like needsFlush() could prevent a loop over all objects.

admin commented

2026-01-22 13:01:41 +01:00

@doctrinebot commented on GitHub (Nov 18, 2010):

Comment created by @beberlei:

No, by default you don't have to call ->persist() for entities that changed at all. Only for new ones.

Doctrine knows the entities that have been retrieved from the database and upon flush it iterates through all of them and tries to detect changes.

@doctrinebot commented on GitHub (Nov 18, 2010): Comment created by @beberlei: No, by default you don't have to call ->persist() for entities that changed at all. Only for new ones. Doctrine knows the entities that have been retrieved from the database and upon flush it iterates through all of them and tries to detect changes.

admin referenced this issue

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

[PR #1088] [MERGED] Fix the composer autoload paths for the doctrine CLT #9143

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