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.
If we decide to stop the driver, we should not reply back before we
have a clean state with all BTrees closed.
Also, implement lookup of existing keys in the tree.
