Get rid of the notion of a special 'Empty' Commit value, which means
that a freshly created Dataset or DataStore will have no Head at
all. To allow callers to tolerate this, we provide the MaybeHead()
method for them to use when they're unsure about whether a given
Data{set,Store} has ever been committed to.
To ease the API impacts of this change, we've also modified Commit()
to take a types.Value and handle creating a Commit struct holding that
Value and descending directly from the current Head.
Callers who wish to provide alternate parents can use CommitWithParents()
This patch changes the "Head" of a DataStore to be a single Commit,
as opposed to a SetOfCommit. This has several consequences:
1) Commit() will only accept Commits that are descendants of the
current Head.
2) Calls to Commit() can now fail, so the method now has an additional
'ok' return value that callers must check. Whether ok is true or
false, the DataStore struct returned is the right one to use for
subsequent calls to Commit() -- retries or otherwise.
3) This rolls up the stack, so Dataset.Commit() can now fail as well,
and similar logic applies.
4) sync.SetNewHeads() also behaves similarly, since it can also now fail.
5) Examples now die on Commit() failures.
Also, removes the /dataset endpoint from server. It's deprecated, and this
patch would have required updating it, so instead just delete it.
Towards issue #147
Also, factor out a separate NewDataStoreWithRootTracker() since
the common case is to use the same value for both the ChunkStore
and the RootTracker.
Fixes#134
We've been keeping some special-case code in Datastore to handle the
situation where the Root of the store is nonexistent. There was some
checking for the empty Ref and creating a SetOfCommit out of whole
cloth. This meant that if you asked an empty Datastore (or Dataset)
what its Heads() were, it would give you back a Value that wasn't
backed by a Chunk in its underlying ChunkStore. This caused some
issues with pull code, so we decided to change things such that a
DataStore is primed with an initial empty SetOfCommit upon creation.
This means creating a Dataset in a DataStore now shows up in DataStore
history, which it did not before. Essentially, every Dataset now has
an "initial commit" of an empty SetOfCommit when it's created. I think
that having these show up as part of the DataStore history makes sense,
but the model may evolve over time.
The test for this does the following:
1. The generated code is checked in
2. Running the test regenerates the generated code
3. Then the test.go is compiled and run
This also adds a smoke test for the codegen which just makes sure
that we do not fail when we try to generate code.
Fixes#90
We want to be able to track individual datasets by name, so
that we can create pipelines that share the same datastore
but create unique views of the shared data.
Addresses issue #22
