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

Additions for antidote db #1

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

santialvarezcolombo
Copy link

Added payload, operation, and snapshot types needed for Antidote DB.

…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
@bieniusa
Copy link
Contributor

What is the state of this PR?
@santialvarezcolombo Is it still needed with the new eleveldb integration plan?
Why are you specifying the types here and not in antidote.hrl?? They are not used in this module and don't seem to be re-usable in other contexts.

@santialvarezcolombo
Copy link
Author

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.

@bieniusa
Copy link
Contributor

Am 30.10.2016 um 20:45 schrieb Santiago Alvarez Colombo notifications@github.com:

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?
You should be able to use the definitions from antidote.hrl if you list antidote as an dependency.

@santialvarezcolombo
Copy link
Author

Wouldn't that create a circular dependency? Even if it doesn't, I think that having them here is a better design choice.

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.

4 participants