Also remove test util code from the two simpler Go samples. I think
we will want to distinguish between "samples" and "utilities". The
former should be as easy to understand and lightweight as possible,
while the latter will tend to be more a real part of the project
that is maintained, tuned, relied upon, etc.
The former should only rely on the Noms SDK and the Go stdlib. The
latter should follow normal Noms internal coding conventions.
As one step towards #1819, we've created MapMutator, which can take a
bunch of (what would normally be) Map.Set() calls and batch them up to
be applied all at once. The keys and values are held in a LevelDB cache
until everything's done. Usage looks like this:
m := types.NewMap()
mx := m.Mx()
mx = mx.Set(String("foo"), String("bar")).Set(String("baz"), Number(42))
m = mx.Finish()
We intend to make this the only way to modify collections, but at first
this will only work on an empty NomsMap.
Previously when we had an ordered (set/map) prolly tree containing
non-ordered values (blobs/refs/etc), we'd put the ref of the largest
value in each meta node, complete with its full type info and height.
This is wasteful, all we really need is the hash of the largest item for
searching the tree. In lieu of encoding just the hash - which isn't a
value - this patch creates a fake Ref<Boolean> with height 0.
There were a few issues here:
1. The version header was not always passed to fetch
2. HTTP headers are case insensitive and Node an Fetch uses lower case.
3. The old code used a Map instead of an object as map. Node and Fetch
uses an object as map. Now we just pass along the response headers.
Fixes#1881Closes#1880 (which this is partially based in)
ChunkStores provide a Version() method so that anyone directly
using a ChunkStore (e.g. BatchStoreAdaptor) can retrieve and
check the version of the underlying store.
remoteDatabaseServer checks the version of the ChunkStore it's
backed by at startup, and then provides that version as an HTTP
header to all clients. In Go, httpBatchStore checks this header
anytime it gets a response from the server and bails if there's
version skew.
In Go, the responsibility for checking whether the running code and
the data being accessed lies with the BatchStore layer. In JS, there
is code in fetch.js that checks the header mentioned above.
Towards #1561
One side effect of the way that Go's flag library works is that any
flag that's defined at the global scope by any library that's built
into your binary shows up in your help -- whether you honor it or
not. Arguably, including the library and calling its entry points
should be tantamount to honoring the flags. This change makes the
profiling flags behave that way -- there's one function that you call
to turn on whichever kinds of profiling the user specifies on the
command line. It returns an object with a Stop() method that you call
to shut down profiling and flush data, like so:
defer profile.MaybeStartProfile().Stop()
Aaron Boodman