Optimistic locking should be enforceable at the framework level [DATAES-674]

[spring-projects-issues]

danielsonjh opened DATAES-674 and commented

When using @Version, the field type needs to be Long.

When the version field is null, spring-data-elasticsearch does not set the version query param in the request to Elasticsearch.

If it's critical to enforce the usage of optimistic locking, currently the best option seems to be to validate / set the version field in the domain object.

It would be convenient if there was an option to either throw an exception for missing versions, or default the version field / query param to 0 at the framework level to make the policy easier to enforce

---

No further details from DATAES-674

[spring-projects-issues]

sothawo commented

what if you initialize your @Version annotated field with a default value of 0?

[spring-projects-issues]

danielsonjh commented

That's my workaround for now, except I have to set it to 0 in the constructor.

This is because the class annotated with @Document is deserialized from JSON using gson, which seems to ignore the field initializers unfortunately: google/gson#1005.

It would be nice to set a config in the framework, instead of adding a constructor to default the value of the @Version field on every class that needs the optimistic locking enforced

[spring-projects-issues]

sothawo commented

with DATAES-799, we now implement optimistic locking based on seq_no and _primary__term (https://www.elastic.co/guide/en/elasticsearch/reference/7.6/optimistic-concurrency-control.html). The entity needs to have a field of type SeqNoPrimaryTerm

[spring-projects-issues]

sothawo commented

With DATAES-799 we now support optimistic locking with seq_no and primary_term in addition to the existing version support.

As for initializing a version field to zero instead to null:

@Version
Private Long version = 0;

should be enough with no need for a separate constuctor