New versioning strategy for optimistic lock: next version value managed by App

[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:

• 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)

[doctrinebot]

Hello,

thank you for creating this pull request. I have automatically opened an issue
on our Jira Bug Tracker for you. See the issue link:

http://www.doctrine-project.org/jira/browse/DDC-2719

We use Jira to track the state of pull requests and the versions they got
included in.

[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:

    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.

[beberlei]

I am afraid the way this works is not acceptable. I would rather have a service generate the next version, getting passed the entity. However I don't like that it changes so much of the Persister internals for this feature, which very very few people are ever going to need, which is why I am not accepting this PR into core. Sorry to disappoint you on this.

[diego-mazzaro]

Hi, my disappointment is very very little becouse I fully understand your points expecially that maybe this feature is useful only for me... Of course if this would have been integrated in the core it would have been more comfortable for me to use doctrine without the need to patch every new version before using it for my work. Neverless I agree with your choice to reject. Bye.

[beberlei]

@diego-mazzaro can you write a mail to the doctrine-user list with your questions from yesterday?

[diego-mazzaro]

Sure, I will write about the possibility to force the update of the version field. Only this will not happen immediately but rather in the near future. I need that feature in my project but I'm not jet to the point where I need it absolutely because now I'm working on other parts of the project. As soon as I come to that topic in my proect I will be in contact with the doctrine community in order to find an appropriate way and prepare a good PR.