DDC-2719: [GH-810] New versioning strategy for optimistic lock: next version value managed by App #3402

New Issue

admin · 2026-01-22T14:19:17+01:00

admin commented

2026-01-22 14:19:17 +01:00

Originally created by @doctrinebot on GitHub (Oct 1, 2013).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user @doctrinebot:

This issue is created automatically through a Github pull request on behalf of diego-mazzaro:

Url: https://github.com/doctrine/doctrine2/pull/810

Message:

With this improvment the next value for the version field used for the optimisic lock strategy can be managed by the application.

_When can be useful?_
Obviously it is useful if we whant different values than the standard and for example:

using also negative numbers
using a combination of datetime and progressive number
mark with the same version all the records touched in a single updating session
anything that I want to do with my app and can be meaningful for me

_And really can be done something different from standard ways?_
The _base property_ that a version column next value must have in order to accomplish his own task is this:
be different from any value that any other concurrently running client/process/thread/session may have read as current version value for the same record.
The opposite may sound more clear: if I write the same value that anyone concurrently working with me has read as current version he will find the same version when writing and will think that all is ok.

That told the standard implementations are:

next version = version + 1: prerfect
next version = TIMESTAMP: not so perfect but someone can live with

This two obviously respects the _base property_ but the point is that they are not the only ones. Some examples:

increment by two: not so strange but different
increment up to 1000 and then restart from 0
- if I'm sure that every session will end before other 1000 session has occourred it can work
use a GUID as version so I will "never" finish the possible values
use strings
- wisely: knowing the "base property"
use values from an autogenerated ID of other table (generated for each updating session)

Originally created by @doctrinebot on GitHub (Oct 1, 2013). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user @doctrinebot: This issue is created automatically through a Github pull request on behalf of diego-mazzaro: Url: https://github.com/doctrine/doctrine2/pull/810 Message: With this improvment the next value for the version field used for the optimisic lock strategy can be managed by the application. **_When can be useful?**_ Obviously it is useful if we whant different values than the standard and for example: - using also negative numbers - using a combination of datetime and progressive number - mark with the same version all the records touched in a single updating session - anything that I want to do with my app and can be meaningful for me **_And really can be done something different from standard ways?**_ The **_base property**_ that a version column next value must have in order to accomplish his own task is this: **be different from any value that any other concurrently running client/process/thread/session may have read as current version value for the same record.** The opposite may sound more clear: if I write the same value that anyone concurrently working with me has read as current version he will find the same version when writing and will think that all is ok. That told the standard implementations are: - next version = version + 1: prerfect - next version = TIMESTAMP: not so perfect but someone can live with This two obviously respects the **_base property**_ but the point is that they are not the only ones. Some examples: - increment by two: not so strange but different - increment up to 1000 and then restart from 0 - if I'm sure that every session will end before other 1000 session has occourred it can work - use a GUID as version so I will "never" finish the possible values - use strings - wisely: knowing the "base property" - use values from an autogenerated ID of other table (generated for each updating session)

admin added the Improvement label 2026-01-22 14:19:17 +01:00

admin closed this issue

2026-01-22 14:19:17 +01:00

admin commented

2026-01-22 14:19:18 +01:00

@doctrinebot commented on GitHub (Oct 3, 2013):

Comment created by diego.mazzaro:

I forgot to give an example of how configuration files has to be written to let this additional versioning mode works.
Here is following with an yml mapping file:

    id:
        id:
            type: integer
            nullable: false
    fields:
        code:
            type: string
            length: 20
            nullable: false
        description:
            type: string
            length: 40
            nullable: false
        [... other data fields ...]
        versionField:
            type: integer
            nullable: false
            version:
                nextVersionProperty: currentTid     # <<= this is the key row to have it working
        [... mappings and other ...]

pratically all remains as usual but if under the "version" label a sub label "nextVersionProperty" is found then the class property with that name will be added to the reflFields so that its value can be used when preparing the INSERT and UPDATE of the versionField.

@doctrinebot commented on GitHub (Oct 3, 2013): Comment created by diego.mazzaro: I forgot to give an example of how configuration files has to be written to let this additional versioning mode works. Here is following with an yml mapping file: ```none type: entity id: id: type: integer nullable: false fields: code: type: string length: 20 nullable: false description: type: string length: 40 nullable: false [... other data fields ...] versionField: type: integer nullable: false version: nextVersionProperty: currentTid # <<= this is the key row to have it working [... mappings and other ...] ``` pratically all remains as usual but if under the "version" label a sub label "nextVersionProperty" is found then the class property with that name will be added to the `reflFields` so that its value can be used when preparing the INSERT and UPDATE of the `versionField`. ```

admin commented

2026-01-22 14:19:18 +01:00

@doctrinebot commented on GitHub (Jan 2, 2014):

Comment created by @doctrinebot:

A related Github Pull-Request [GH-810] was closed:
https://github.com/doctrine/doctrine2/pull/810

@doctrinebot commented on GitHub (Jan 2, 2014): Comment created by @doctrinebot: A related Github Pull-Request [GH-810] was closed: https://github.com/doctrine/doctrine2/pull/810

admin commented

2026-01-22 14:19:18 +01:00

@doctrinebot commented on GitHub (Jan 2, 2014):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Jan 2, 2014): Issue was closed with resolution "Won't Fix"

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