Quviq/leveled/issues/13 shows the confusion around the purpose of
start key. Hopefully this commit clarifies that start key is a further
refinement to the range start. It's essentially and AND.
If ther are backups made to the same folder, need to remove any files from that folder that are not included in this backup.
Some initial testing, needs more.
As the fold functions have been added to get_runner in an ad hoc way,
naturally, given the ongoing development of levelEd to support Riak,
it was difficult for a new user (in this case Quviq) to see what folds
are supported, and with what arguments, and expectations.
This PR is for discussion. It is one of many ways to group, spec, and
document the fold functions.
A test is also added for coverage of range queries.
During EQC testing it was found that snapshots are still usable even
if the bookie process crashes. This change has snapshots monitor the
bookie and close when the bookie process dies.
head_only mode cna be run with_lookup - but there is no L0 index created in this case.
So the L0 index wasn't returning a potition list and the L0 cache wasn't being checked.
Code now checks every position in the L0 cache, when a lookup is attempted in head_only mode.
The scan_table situation where the query needs to be start inclusive, was consistently getting coverage. It was less likely to get coverage with smaller cache sizes.
It is not clear why this wasn't being triggered before. Perhaps because of the erroneous jitter setting?
Multiple cache sizes now tested to try and make sure the test is always in-line with expectations.
Interetsingly setting max_pencillercachesize to a non-integer merely had the impact of making the penciller cache size infinite.
So a guard added to make sure it is an integer going forward.
Make it easier to discover all the options and the defaults from reaidng the code.
Note default sync option is now none. This doesn't mean this is recommended
ets:next is not StartInclusive - so we shouldn't use ets:next when querying the ledger cache, until it has been confirmed thta a matching key to the StartKey is not present.
This reoslves the intermittently failing unit test which highlighted this (and also makes that intermittent failure a permanent failure by expanding the test cases it covers).
Previously there was no is_empty check, and there was a workaround using binary_bucketlist. But what if there were many buckets - this is a slow seek (using get next key over and over).
Instead have a proper is_empty check.
