Optional support for relative numerical update instead of absolute #5343

Closed
opened 2026-01-22 15:05:04 +01:00 by admin · 2 comments
Owner

Originally created by @Goatfried on GitHub (Dec 7, 2016).

Originally assigned to: @Ocramius on GitHub.

Hello,
If I haven't missed anything, doctrine currently doesn't support relative updates of numerical fields besides the fixed behaviour of level.

When integer fields changed, they are updated via column = new value.
A relative updated via column = column - (new value - old value) would be nice in some cases with concurrent updates on the same data.
Since postUpdate Events can only change the new value absolute as well, we've to perform an additional query in the preUpdate Event - either an update or a select.

This is helpful in cases with concurrent access where updates can't be made fully transactional.
Let's say, we have a long running process that updates some things based on a flag on the entity. When the process is finished, we want to update the entity. But, if another trigger occurred meanwhile, either their column update would be lost or we could work with a lock exception that closes the entity manager.

Another use case could be a customer - sales relation where we want to store the total sales volume on the customer for performance reasons.

Is there currently any way to solve this and i've missed it or work on it? If not, I'd like to start working on such a feature.

Originally created by @Goatfried on GitHub (Dec 7, 2016). Originally assigned to: @Ocramius on GitHub. Hello, If I haven't missed anything, doctrine currently doesn't support relative updates of numerical fields besides the fixed behaviour of level. When integer fields changed, they are updated via column = new value. A relative updated via column = column - (new value - old value) would be nice in some cases with concurrent updates on the same data. Since postUpdate Events can only change the new value absolute as well, we've to perform an additional query in the preUpdate Event - either an update or a select. This is helpful in cases with concurrent access where updates can't be made fully transactional. Let's say, we have a long running process that updates some things based on a flag on the entity. When the process is finished, we want to update the entity. But, if another trigger occurred meanwhile, either their column update would be lost or we could work with a lock exception that closes the entity manager. Another use case could be a customer - sales relation where we want to store the total sales volume on the customer for performance reasons. Is there currently any way to solve this and i've missed it or work on it? If not, I'd like to start working on such a feature.
admin added the ImprovementInvalid labels 2026-01-22 15:05:04 +01:00
admin closed this issue 2026-01-22 15:05:04 +01:00
Author
Owner

@Ocramius commented on GitHub (Dec 7, 2016):

Since postUpdate Events can only change the new value absolute as well, we've to perform an additional query in the preUpdate Event - either an update or a select.

The ORM would have to do that for you anyway.

The assumption is really simple: Entity state needs to be reflected on the DB after flush. The authoritative state is the in-memory one, and the ORM will not change your entities.

@Ocramius commented on GitHub (Dec 7, 2016): > Since postUpdate Events can only change the new value absolute as well, we've to perform an additional query in the preUpdate Event - either an update or a select. The ORM would have to do that for you anyway. The assumption is really simple: Entity state needs to be reflected on the DB after flush. The authoritative state is the in-memory one, and the ORM will not change your entities.
Author
Owner
@Ocramius commented on GitHub (Dec 7, 2016): Also check http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/transactions-and-concurrency.html
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5343