Tree nodes now hold entries at the form
{Key, ?TOMBSTONE
| BinValue
| {?TOMBSTONE, TStamp}
| {BinValue, TStamp}}
We use the form without TStamp when expiry_secs
is unset or set to 0 (i.e., values don't expire).
merger/writer: Move KV count into writer, because
now the writer:add determines if a value is expired
and thus wither a value is actually written. Thus,
writer now has a new API function which returns the
KV count written so far.
reader: lookup/fold API hides the TStamp tuples,
so only the next_node API used by the merger
is exposed to these {Key, {_, TStamp}} entries.
nursery: like reader, the TStamp'ed tuples are
not exposed in the client API; expired values
are simply not returned from fold/lookup.
hanoidb: add config option {expiry_secs, N}.
other modules: Make sure that config is passed
all the way down through (sub) processes to be
able to utilize the config option everywhere.
test: update to work with new option.
In some cases, inner nodes were not being emitted.
This some times would cause queries (get / range_fold)
to only include results in a right-most branch.
This slows down insert to be log2(N), where N is
the total number of objects in the store. The upside
is that it also removes the terrible worst case
scenarios for insert.
* Added copyright notices to files
* Added Apache 2.0 License file with permission from Kresten/Trifork
* Changed the handle from "Db" to "Tree" because... it made me feel better
* Other minor changes here and there
Sync blocks insert/lookup while doing a range
query, but still buffers the results in a
per-range query process.
Async fold runs on a hard link copy of the
underlying tree data.
This commit and also fixes a number of bugs
related to folding; it was not taking nursery
data into account.
Problem is that we sometimes get errors resulting
from files being written as a result of pending
merges. Closing a tree should stop all such
file-level activity.
First implementation of range fold
Range folding doesn't prohibit insert/lookup or
merge operations, but each level can only have
one range fold operation active.
Thus, worst case active range folds can double
space requirements, because it holds hard-linked
copies of used btree files.
A dict is open and with keys if its size is greater than 0. Go through
the dicts one by one with lists:any/2 and use that to optimize the
check. Ought to run faster than traversing the full set.
To make failing keys work we must be able to produce a key in fewer
failures then currently. So encode the picker for non-empty trees
directly so it is much faster and doesn't try to do it by generating a
case and then asking "is this one good enough?". A simple
dict:filter/2 does it.
This patch implements another possible command: Lookup of keys that
already exist in the tree somewhere. We use a dict as the test tool:
the postcondition verifies that the value obtained from the fractal
btree matches the one we put in the dict earlier.
