mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
DDC-2864: New type of lock: OPTIMISTIC_FORCE_INCREMENT #3574
Reference in New Issue
Block a user
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?
Originally created by @doctrinebot on GitHub (Dec 18, 2013).
Originally assigned to: @beberlei on GitHub.
Jira issue originally created by user szjani:
When optimistick locking is being used, the version field is incremented after the update only if the entity itself has been modified. In Domain-Driven Design another kind of locking mechanism is essential: OPTIMISTIC_FORCE_INCREMENT. It means that the version field is always incremented after an update. The lack of this feaure can be realized when only the aggregate root has a version field and some other parts of the aggregate is being modified.
PESSIMISTIC_FORCE_INCREMENT is also an interesting lock type which might be useful as well.
@doctrinebot commented on GitHub (Dec 18, 2013):
@doctrinebot commented on GitHub (Mar 26, 2015):
Comment created by dhager:
I'm having this same issue, although I'm not certain a new locking-type is the answer.
Basically, I want to ensure that an entity gets updated with a new version integer/timestamp, whether or not anything "real" has been changed on it. It seems the only workaround is to designate a "junk" property and change that, which isn't particularly elegant.
The problem with a locking-type is that individual entities can't signal that they need incrementing without having a reference to the entity-manager so that they can $em->lock() .
@beberlei commented on GitHub (Dec 5, 2020):
Implementation, during
UnitOfWork::computeChangeSetseach active metadata type is iterated via the identity map .For each entity check if it has forced optimistic increment, if that is the case mark the entity as to be updated even ifcomputeChangeSetdoes not have changes. It might be necessary to mark the version column as changed, similar how its done for the regular version strategy.