-
Notifications
You must be signed in to change notification settings - Fork 0
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
Additions for antidote db #1
base: master
Are you sure you want to change the base?
Conversation
…nto additions_for_antidote_db * 'master' of https://github.com/SyncFree/antidote_utils: more precise dcid definition
stored by antidoteDB.
…ee/antidote_utils into additions_for_antidote_db * 'additions_for_antidote_db' of https://github.com/SyncFree/antidote_utils: Updated snapshot record
…tidote_utils into additions_for_antidote_db * 'vectorclock-renaming' of https://github.com/SyncFree/antidote_utils: renamed vectorclock functions strict_ge to gt and strict_le to lt renamed vectorclock functions
# Conflicts: # include/antidote_utils.hrl
What is the state of this PR? |
At first, my leveldb code wasn't assuming anything on the type of the values to be stored in the DB. Tyler pointed out that I should use log_record and materialized_snapshot, which makes a lot of sense to provide a consistent API. Since AntidoteDB is a standalone module, I don't have access to antidote.hrl, and therefore need this values either in the module, or here. I think that having them here is more appropriate, despite that today they aren't re-used in any other context. |
I am not sure what you mean with you don’t have access? |
Wouldn't that create a circular dependency? Even if it doesn't, I think that having them here is a better design choice. |
Added payload, operation, and snapshot types needed for Antidote DB.