Skip to content

implement versionstamp bindings for tuple layer #128

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

Closed
pH14 opened this issue Jul 10, 2019 · 1 comment · Fixed by #143
Closed

implement versionstamp bindings for tuple layer #128

pH14 opened this issue Jul 10, 2019 · 1 comment · Fixed by #143

Comments

@pH14
Copy link
Collaborator

pH14 commented Jul 10, 2019

Versionstamps are a compelling feature that tie in closely with the tuple layer, and are the main thing currently missing from it right now.

They have a bit of a weird API, where you encode an incomplete versionstamp to a tuple, pack the tuple with a special offset (w/ different values depending on FDB client version), write the resulting bytes with the SET_VERSIONSTAMP_(KEY|VALUE) atomic operations, and then FDB magically replaces the incomplete-versionstamp portion of the tuple with the actual commit-time versionstamp when it writes to disk.

They were recently added to the golang bindings: https://github.com/apple/foundationdb/pull/1187/files which makes for a nice distillation of what they need to work.

That said: they do puncture a bit of the clean implementation of tuples we have now, since they add some new invariants:

  • vanilla packing of a tuple cannot contain an incomplete versionstamp, otherwise it fails
  • versionstamp-packing a tuple must contain exactly one incomplete versionstamp, otherwise it fails
@pH14
Copy link
Collaborator Author

pH14 commented Jul 10, 2019

FWIW I'm working on this one right now and have a very janky implementation that reads/writes them. Hopefully will get up a more polished PR in a reasonable amount of time.

I do wonder if there's some clever way to encode the exactly-one incomplete versionstamp invariants into the type system, but that's beyond what I've looked into so far.

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 a pull request may close this issue.

1 participant