Configure the exposition of the @Version property in request body [DATAREST-1448]

[spring-projects-issues]

genglefr opened DATAREST-1448 and commented

Would it possible to configure the exposition in the body of the @Version property?

My case is the following:

@LastModifiedDate
@Version
private Instant modifiedOn;

• I'm using @Version annotated Instant field
• This field is useful to know when the entity was modified last time
• I cannot use the Etag header in collection response body since every entity of the collection has different last modification date

In the default configuration, the resource assembler simply transforms the @Version property into Etag and swallows it from the response body

---

Affects: 3.2 GA (Moore)

1 votes, 1 watchers

[alienisty]

Differently from the entity id exposition, it would be convenient to be able to generally enable the exposition of version fields. That would allow to support optimistic locking without having to enable the exposition of the version field for each entity.

[odrotbohm]

The version is exposed via the ETag header to support the HTTP If-Match / If-Non-Match headers for conditional requests.

I cannot use the Etag header in collection response body since every entity of the collection has different last modification date

Can you elaborate on that? The general contract for If-(None-)Match headers is that they're supposed to be used with ETag values in the first place. I.e. you have to look up the ETag value of an item resource in the first anyway.

[odrotbohm]

@alienisty on #1981:

Yes I do, but we, currently, only process the response body from the Angular HttpClient. We want to look into improving our adherance to REST principles but that is a long roadmap at this point. Being able to expose the version field would allow us to incrementally "fix" our application.

I don't think we should cater that corner case. There's a definition of hoe ETag and If-(None-)Match are supposed to work. "We currently don't read headers" is not a convincing argument, especially as you apparently already send headers. There's a well-specified approach to this and that is already supported out of the box. So I am inclined to close this as won't fix.

[alienisty]

We use the version to enable optimistic locking which spring data JPA supports. So far we have been including the version to the JSON payload we send to the server when we update a resource to ensure consistency.
This section of the reference documentation, doesn't specify if the conditional operations are implemented through optimistic locking.
We are not asking to change the way the framework works, just allow to optionally include in the paylod the version field as it is already done for the id of an entity.