This repository has been archived by the owner on Nov 29, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 45
[feature] add support to remove_all keys atomic operation #38
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
07343fe
[feature] add support to remove_all keys atomic operation
akichidis e33ae00
[feature] remove extern crate
akichidis 749ea08
[feature] introduce method to atomically remove multiple keys
akichidis d9cb143
[feature] introduce more bulk atomic methods for write & read all
akichidis 6ae1289
[feature] did run linter
akichidis c37d3ae
[feature]: changed the reference slice to iterator
akichidis File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure that there is value doing this (we do similar for the single Delete operation). Based on the implementation of the
notify_read
the obligation:in order for an obligator to be notified when a value gets deleted we should have a value already in place, which means that the obligator will have already received a notification via the earlier
write
operation and then get popped up by the queue.The other alternative would be to just notify irrespective of whether we do have a successful delete or not - but again don't know what's the value then.
I might be missing a case here, but if we don't see this possible I would lean towards removing this code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The goal of the
notify_read
operation is indeed to implement a post-write callback signal.The use case is to make sure you only move on when you have guarantees you'll be able to recover from a process crash through persistence, and in practice we use it as a barrier (i.e. you have X writes to perform and only move on when they've all been done). I've never seen the value of a
notify_read
actually used or inspected, but rather always discarded: the signal is we're done with the next write operation on those keys, rather than the details of the written semantics.Does that make things more clear? I agree that the name
notify_read
and the discipline of actually returning the value when we don't use it are confusing, and that there are probably simplifications to be found there. But I think discharging an obligation on a delete makes sense to me.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I guess looking on the code of
notify_read
it seemed to me that the caller will want to get notified once the data are written by someone (becoming available) ....to give an analogy, like a one-off pub/sub with persistence. Ok cool, I'll leave as is then, but it seems that we might need to iterate this in the future , but probably not a priority for now.