doctrine/archived-orm
1
0
Fork 0
mirror of https://github.com/doctrine/orm.git synced 2026-03-24 06:52:09 +01:00
Code Issues 5.3k Packages Projects Releases 100 Wiki Activity

DDC-414: Improve Performance of onUpdate Event Listeners #515

New Issue
Closed
opened 2026-01-22 12:41:04 +01:00 by admin · 7 comments
admin commented 2026-01-22 12:41:04 +01:00
Owner
Copy Link

Originally created by @doctrinebot on GitHub (Mar 12, 2010).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user @beberlei:

Currently both onUpdate lifecycle events and event listeners trigger the recomputeEntityChangeSets method.

I would suggest to change the event listeners to only recieve a reference of the changeset and not computing the differences for each affected entity. This could improve performance considerably in the onUpdate event case and would be more helpful for users to understand how limited the onUpdate event listener really is.

Originally created by @doctrinebot on GitHub (Mar 12, 2010). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user @beberlei: Currently both onUpdate lifecycle events and event listeners trigger the recomputeEntityChangeSets method. I would suggest to change the event listeners to only recieve a reference of the changeset and not computing the differences for each affected entity. This could improve performance considerably in the onUpdate event case and would be more helpful for users to understand how limited the onUpdate event listener really is.
admin added the Improvement label 2026-01-22 12:41:04 +01:00
admin closed this issue 2026-01-22 12:41:05 +01:00
admin commented 2026-01-22 12:41:06 +01:00
Author
Owner
Copy Link

@doctrinebot commented on GitHub (Mar 12, 2010):

Comment created by @beberlei:

Another valid approach would be to require an explicit call to recomputeEntityChangeSets from an onUpdate listener.

I think both use-cases could be supported.

@doctrinebot commented on GitHub (Mar 12, 2010): Comment created by @beberlei: Another valid approach would be to require an explicit call to recomputeEntityChangeSets from an onUpdate listener. I think both use-cases could be supported.
admin commented 2026-01-22 12:41:06 +01:00
Author
Owner
Copy Link

@doctrinebot commented on GitHub (Mar 12, 2010):

Comment created by @beberlei:

This would be a BC break, so implementation before Beta 1 seems a necessary must

@doctrinebot commented on GitHub (Mar 12, 2010): Comment created by @beberlei: This would be a BC break, so implementation before Beta 1 seems a necessary must
admin commented 2026-01-22 12:41:06 +01:00
Author
Owner
Copy Link

@doctrinebot commented on GitHub (Mar 12, 2010):

Comment created by romanb:

Well, ok, we can still have BC breaks during BETA though, only once we hit RC the API is frozen.

@doctrinebot commented on GitHub (Mar 12, 2010): Comment created by romanb: Well, ok, we can still have BC breaks during BETA though, only once we hit RC the API is frozen.
admin commented 2026-01-22 12:41:08 +01:00
Author
Owner
Copy Link

@doctrinebot commented on GitHub (Mar 14, 2010):

Comment created by @beberlei:

Attached is a proposed implementation example

@doctrinebot commented on GitHub (Mar 14, 2010): Comment created by @beberlei: Attached is a proposed implementation example
admin commented 2026-01-22 12:41:08 +01:00
Author
Owner
Copy Link

@doctrinebot commented on GitHub (Mar 14, 2010):

Comment created by @beberlei:

Implemented, notes in UPGRADE_TO_2_0:

## Change of PreUpdate Event Listener

Event Listeners listening to the 'preUpdate' event can only affect the primitive values of entity changesets
by using the API on the `PreUpdateEventArgs` instance passed to the preUpdate listener method. Any changes
to the state of the entitys properties won't affect the database UPDATE statement anymore. This gives drastic
performance benefits for the preUpdate event.
@doctrinebot commented on GitHub (Mar 14, 2010): Comment created by @beberlei: Implemented, notes in UPGRADE_TO_2_0: ``` ## Change of PreUpdate Event Listener Event Listeners listening to the 'preUpdate' event can only affect the primitive values of entity changesets by using the API on the `PreUpdateEventArgs` instance passed to the preUpdate listener method. Any changes to the state of the entitys properties won't affect the database UPDATE statement anymore. This gives drastic performance benefits for the preUpdate event. ```
admin commented 2026-01-22 12:41:08 +01:00
Author
Owner
Copy Link

@doctrinebot commented on GitHub (Mar 14, 2010):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Mar 14, 2010): Issue was closed with resolution "Fixed"
admin commented 2026-01-22 12:41:09 +01:00
Author
Owner
Copy Link

@doctrinebot commented on GitHub (Dec 13, 2015):

Imported 1 attachments from Jira into https://gist.github.com/9c43acb2ee7307de0296

@doctrinebot commented on GitHub (Dec 13, 2015): Imported 1 attachments from Jira into https://gist.github.com/9c43acb2ee7307de0296 - [10459_ddc414.patch](https://gist.github.com/9c43acb2ee7307de0296#file-10459_ddc414-patch)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BC Break
Bug
Can't Fix
Deprecation
Documentation
DQL
Duplicate
Failing Test
Hacktoberfest
Improvement
Improvement
Incomplete
Invalid
Missing Tests
New Feature
PR Created
pull-request
Mirrored from GitHub Pull Request
 Question
Regression
Status: Waiting feedback
Waiting feedback
WIP
Won't Fix
No Label Improvement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#515
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?