This allows setting the meta field when you commit.
This is a version change because the signature of Database commit
changed in a non backwards compatible way. It now takes an optional
third options object instead of an optional array.
Noms SDK users frequently shoot themselves in the foot because they're
holding onto an "old" Database object. That is, they have a Database
tucked away in some internal state, they call Commit() on it, and
don't replace the object in their internal state with the new Database
returned from Commit.
This PR changes the Database and Dataset Go API to be in line with the
proposal in Issue #2589. JS follows in a separate patch.
In service of streaming set and map mutators, it'd be helpful for
ValueStore to implement some methods that are exposed only to other
code within the types package, even when a ValueStore is embedded
in a Database. That said, we don't want those methods to become a
part of the public Database API.
To enable this, this patch changes databaseCommon to embed a
*types.ValueStore, instead of composing one. This causes all the
ValueStore methods to be a part of the databaseCommon API, but
since all the Database construction methods return a Database by
interface, stuff like BatchStore() all gets masked. Thus, callers
still can't access ValueStore methods. Databases are passed into
the types package as ValueReadWriters, though, so code in there
can call any method on that interface -- including unexported stuff.
The Dataset.Commit() code pathway still enforces fast-forward-only
behavior, but a new SetHead() method allows the HEAD of a Dataset to
be forced to any other Commit.
noms sync detects the case where the source Commit is not a descendent
of the provided sink Dataset's HEAD and uses the new API to force the
sink to the desired new Commit, printing out the now-abandoned old
HEAD.
Fixes#2240
LocalDatabase generally uses a BatchStoreAdaptor, which is a kinda
dumb wrapper around ChunkStore. During a Pull(), though, this would
cause Chunks to be Put in a top-down fashion, meaning that Chunks
wound up in the backing store _before_ other Chunks that they
reference. This means that LocalDatabases were transiently invalid,
and that cancelling an in-progress pull could lead to an invalid DB.
Now, calling validatingBatchStore() on a LocalDatabase returns a
BatchStore that uses the same strategy as RemoteDatabaseClient,
caching chunks as the come in and putting them into the backing store
bottom-up when Flush() is called.
Fixes#1915
Change Dataset.Pull to use a single algorithm to pull data from a
source to a sink, regardless of which (if any) is local. The basic
algorithm is described in the first section of pulling.md. This
implementation is equivalent but phrased a bit differently. The
algorithm actually used is described in the second section of
pulling.md
The main changes:
- datas.Pull(), which implements the new pulling algorithm
- RefHeap, a priority queue that sorts types.Ref by ref-height and
then by ref.TargetHash()
- Add has() to both Database implementations. Cache has() checks.
- Switch Dataset to use new datas.Pull(). Currently not concurrent.
Toward #1568
Mostly, prune reachableChunks
Erik Arvidsson