Write log, as_of time and prep for replication about cayley

[barakmich]

@kortschak : Before I get much farther, I'd like to ask you to take a look at https://github.com/barakmich/cayley/tree/log_database , specifically graph/quadwriter.go and the writer/ directory. It works with memstore (which is now append-only), and I have similar plans for the other two backends, but I wanted your thoughts on interface and design and naming and such first.

The point is to abstract the adding and removing of quads to another module, that can do all the (possibly distributed) synchronization and replication work. Largely, it prints monotonically increasing change IDs that are globally understood, and, (in a later change to the interface), also retrieve ranges of these IDs. For a single machine, the implementation is trivial, so that's what you see here. It also starts to address better error handling on writes.

The reason for being append-only is that it's a lot easier to be consistent if you do it that way, and has the added benefit of a future "as_of_time" feature, which is one of the cool things old graphd did (leaving clients with a choice of Consistency or Availability in a CAP sense)

[kortschak]

Do we need to have WriterMethods()? If people are registering things and forgetting what is available they are probably making a mistake. That mistake will be found by a panic.

A question that's arisen in my looking at TripleStore comes up here too, is it necessary to have both an AddQuad(*quad.Quad) error and and AddQuadSet([]*quad.Quad) error rather than an AddQuads(...*quad.Quad) error? It might be worth measuring the difference betweemn AddQuad(*quad.Quad) and a call to AddQuads(...*quad.Quad) with a single element. If it's not terribly worse, the simplification of the interface would be nice. If you do that then you can define two very simple interfaces, QuadAdder and QuadRemover.

Apart from that I think it all looks fine.

Not in your question, but in writers, I'd use atomic add for the next ID rather than a mutex (and if you stick with a mutex don't defer the unlock).

Also aside, I'll wait for this to go in before I go trough and clean up the Triple naming left throughout.

[kortschak]

Addition to previous, the merits of splitting the interface are up to you. If you think there are times when it makes sense to have only addition, say, then it should be split. Otherwise leave it as a compound interface.

The other thing that may be worth considering is the impact of interleaving add and remove operations. This prevents block insertion since now each addition is separate.

[barakmich]

Interleaving can be done in the future, and it shouldn't impact things too much. Some prep work may be done in the QuadWriter; that's okay.

As for the compound-interface bit, I can't think of a time when removing shouldn't be an interface option, and if I'm wrong, then we can split it when necessary.

How does AddQuads(...quad.Quad) change with the fact it no longer takes pointers? If it's a non-issue, then sure, AddQuads() as the only adder (likewise RemoveQuads) makes sense. But, now there's a PR at #113 open for comment :)

[kortschak]

AddQuads(...quad.Quad) behaves as AddQuad([]quad.Quad) if the parameter is a []quad.Qaud... (the slice is handed in), a new slice with the contents of the variadic list is created in the other case (when the parameters are a list of quad.Quad), but this is not significantly different in the pointer versus concrete case - though measurement is important to look at how the slice element size impacts on it (machine word versus 4 x 2 x machine word).

I just saw the PR, will have a look tonight.