Jira issue originally created by user @doctrinebot:
This issue is created automatically through a Github pull request on behalf of diego-mazzaro:
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:
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:
This two obviously respects the base property but the point is that they are not the only ones. Some examples:
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
[... other data fields ...]
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`.
Comment created by @doctrinebot:
A related Github Pull-Request [GH-810] was closed:
Issue was closed with resolution "Won't Fix"