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

save() doesn't return updated entity if immutable properties used for @id or @version [DATACOUCH-625] #936

Closed
spring-projects-issues opened this issue Oct 6, 2020 · 3 comments
Assignees

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Oct 6, 2020

jpringle opened DATACOUCH-625 and commented

I've been experimenting with an optimal combination of Lombok annotations, generated identity fields and version support.

Along the way, I've found that if the identity field or the version field are immutable (and thus with() methods used for property updates) then the property updates applied during save() are not propagated back to the returned object instance.

This appears to be due to expecting the updates to be applied to the passed in object instance, but "withers" return new object instances which are dropped along the way.

Ie, in ReactiveUpsertByIdOperationSupport.one():

    @Override    public Mono<T> one(T object) {
      return Mono.just(object).flatMap(o -> {
        CouchbaseDocument converted = template.support().encodeEntity(o);
        return template.getCollection(collection).reactive()
            .upsert(converted.getId(),
                    converted.export(),
                    buildUpsertOptions()).map(result -> {
              template.support().applyUpdatedCas(object, result.cas());
              return o;
            });
      }).onErrorMap(throwable -> {
    ...
    }

the object instance "o" (or "object") is never updated with the generated Id value or the result of "applyUpdatedCas()" if the property accessor results in a new object instance (as is the case with "wither" and final properties)


Referenced from: pull request #274

Backported to: 4.0.5 (Neumann SR5)

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Oct 6, 2020

Michael Reiche commented

Would not making those fields immutable be a solution?

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Oct 7, 2020

jpringle commented

well sure, but then you can't follow the documentation's advice for modeling objects.

Ie - it seems the contract being offered by the higher-level spring data mapping constructs is "you can (and should) use immutable objects, just make sure to provide wither methods for id and version properties", but spring data couchbase's implementation falls short.

In the spirit of "it just works if I follow the instructions and advice", I'd expect to be able to use this simple immutable data class w/o gymnastics:

 

@Value
@Document
public class Person {
  @Id @With String id;
  @Version @With long version;
  @Field String fName;
  @Field String lName;
}

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Oct 22, 2020

Michael Reiche commented

fixed 
template.support().applyUpdatedCas
and calling code, added
template.support().applyUpdatedId

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants