Implement :db/noHistory

[rnewman]

We currently ignore this entirely. It might be useful to allow this to be set.

The goal is to avoid spending lots of disk on obsolete facts. It's not entirely clear to me how to reconcile "it's only a storage hint, not a logical directive"[1] with the ability to query history, but I guess figuring out how to do so is part of solving this issue!

There are a few potential implementation strategies that I haven't thought through:

• Delete all obsoleted rows in the transaction log when a new row is about to be inserted.
• Replace the earliest consistent value in the transaction log with the new value.
• Replace the value, or all columns, with nulls in previous rows in the transaction log.
• Don't write these datoms to the log at all.

[1] http://datomic.narkive.com/gIuZhcp8/db-nohistory

[rnewman]

Something else that occurred to me, talking to Marco. Something like frecency might be modeled as a noHistory attribute, and the best approach would perhaps be a separate datoms table altogether. We already have the idiom in place to query different datoms tables based on the attribute: we use this for fulltext attributes, and we'll eventually use this for #33.

[rnewman]

This very likely needs some integration with syncing, and will overlap a little with excision (#21) — after all, in our storage layer it's similar to a weak excision of pairs of datoms that have been asserted and retracted, but we can't excise until the retraction has made it to the server.