Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
spring-projects-issues opened this issue Oct 30, 2019 · 4 comments
Assignees
Labels
status: feedback-provided type: enhancement

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Oct 30, 2019

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
Copy link

@alienisty alienisty commented Jul 16, 2021

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
Copy link
Member

@odrotbohm odrotbohm commented Jul 16, 2021

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 odrotbohm added status: waiting-for-feedback type: enhancement and removed in: repository type: bug labels Jul 16, 2021
@odrotbohm
Copy link
Member

@odrotbohm odrotbohm commented Jul 16, 2021

@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
Copy link

@alienisty alienisty commented Jul 16, 2021

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.

@spring-projects-issues spring-projects-issues added status: feedback-provided and removed status: waiting-for-feedback labels Jul 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: feedback-provided type: enhancement
Projects
None yet
Development

No branches or pull requests

3 participants