Queries that in Riak will be based on fold_keys need to be able to catch throws, and re-throw them to be detected by the worker (whilst still clearing up the snapshot)
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.
Due to the internal fold over buckets returning an un-reversed
accumulator, the API bucketlist code caller's fold fun traversed the
bucket list in reverse order. This lead to some inconsistencies when
comparing a buckelist of all buckets, vs, first bucket only. i.e. the
'first' bucket passed to the foldfun was in fact the last bucket read
from the ledger.
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.
Added a test with back-to-back backups. This caused issues with the empty CDB file it created (on opening, couldn't cope with last key of empty).
So now backup won't roll the active journal if it is empty.
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.
There were some bad specs in '|' OR'd specs. These were being falsely ignored in dialyzer until https://github.com/erlang/otp/pull/1722.
Running on OTP21 exposed these incomplete specs.
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
