tree fb26b0e14fc2dc82b098b317573f85be4dbc353e
parent 3ab00369a9b46cfd42a651a4f2347480b9bd9b19
author Sergey Rogulenko <rogulenko@google.com> 1429643575 -0700
committer Sergey Rogulenko <rogulenko@google.com> 1429643577 -0700

Internal storage engine api

This API seems to be a subset of Spanner API.
Looks like it's easy to implement it on top of leveldb.
Some rationale:
- strings are used instead of []bytes as strings are immutable;
  also returned values can point to char arrays allocated on C side
- writes can be done only as a part of transaction as Spanner and
  Sqlite do it anyway, leveldb does a write as a WriteBatch with
  one mutation
- no helpers for operations required by sync: for updating object
  version read+write should happen anyway; to help simulating commit
  log we can use Jatin's time stamps
- I like separation of read-write transactions and snapshots because
  of typesafety; also Spanner does it
- I don't see why for transactions we need to have a consistent snapshot
  that was taken not later than the first read operation in the
  transaction; I feel that snapshot taken at some near future time
  will still be OK
- Snapshot has Close() method as some structs may be allocated on C side
  and in this case we need to do garbage collecting manually; in order
  to get rid of it we can use go finalizers, but they are not as nice
  as Java finalizers because you can't attach them in the middle of
  your struct
- ResetForRetry is a small optimization in case of leveldb as it's
  a bit faster to reuse WriteBatch std::string buffer instead of
  allocating new struct; also Spanner has it

The next two steps will be:
1) forward method calls to leveldb, skipping transaction semantics
2) implement in-memory transactions

Change-Id: I0dcec921d57be8d3b5ec03deae9e00652b9bad64