Skip to content

DATACOUCH-1041 - Add withCas() method to RemoveById. #1051

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

Merged
merged 1 commit into from
Feb 16, 2021

Conversation

mikereiche
Copy link
Collaborator

Add withCas() method to RemoveById as the cas in the entity cannot be used as the entity is not pass in the API. The other option was to add methods like one(T entity) and all(Collection), but those class with one(String id) and all(Collection ids).

  • You have read the Spring Data contribution guidelines.
  • There is a ticket in the bug tracker for the project in our JIRA.
  • You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
  • You submit test cases (unit or integration tests) that back your changes.
  • You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

@mikereiche mikereiche requested a review from daschl January 15, 2021 02:16
Add withCas() method to RemoveById.
@mikereiche mikereiche force-pushed the datacouch_1041_add_withCas_to_RemoveById branch from 6cbc63f to cf820ce Compare January 15, 2021 02:17
Copy link
Contributor

@daschl daschl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me overall, but I think we can get rid of the boxing for less gc

interface ExecutableRemoveById extends RemoveByIdWithDurability {}
interface RemoveByIdWithCas extends RemoveByIdWithDurability {

RemoveByIdWithDurability withCas(Long cas);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this a boxed long and not an unboxed long?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So that null can have different semantics than zero.

@@ -45,17 +46,19 @@ public ExecutableRemoveById removeById() {
private final PersistTo persistTo;
private final ReplicateTo replicateTo;
private final DurabilityLevel durabilityLevel;
private final Long cas;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, could this be a primitive long?

interface ReactiveRemoveById extends RemoveByIdWithDurability {}
interface RemoveByIdWithCas extends RemoveByIdWithDurability {

RemoveByIdWithDurability withCas(Long cas);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see above w.r.t boxing

@@ -81,28 +83,36 @@ private RemoveOptions buildRemoveOptions() {
} else if (durabilityLevel != DurabilityLevel.NONE) {
options.durability(durabilityLevel);
}
if (cas != null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the boxing and null, but it could just check if != 0 ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comes from a comment made by Mark Paluch on another change-set regarding Expiry(I think). It's not quite the same for CAS, but I wanted to keep the same pattern/semantics - that null means "never been set/not specified", while an Object (including an object with value 0) means that it has been set.

#292 (review)

In other words - something like this - That if it was set to non-Zero by an annotation, then there was no way to override (unset) it with the fluent call because it was already non-Duration.zero and the fluent call had to set it to Duration.zero, but Duration.zero (from the fluent call or otherwise) is treated as "never been set", so the value from the annotation would not be overridden. So null would have the semantics of "never been set", and Duration.zero has the semantics of "been set to zero".

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

Successfully merging this pull request may close these issues.

2 participants