Josef Ezra
Josef Ezra
…ulti target by records" At this step, we still keep the old `IndexingByRecords` module - used for implementing `buildRange`, `splitIndexBuildRange`, `buildUnbuiltRange`,`buildEndpoints`. Maybe it'll be possible to delete it after implementing...
After gaining some confidence in the "multi target by records" indexing path, change the code to let the "single target by records" be a private case of one item in...
Let the functions `scrubDanglingIndexEntries` and `scrubMissingIndexEntries` return the count of bad items found instead of void.
This will require, of course, that all the target indexes are covered by the (single) source index.
To support this, we'll probably need: 1. Have a way to online index cumulative indexes in SNAPSHOT resolution (https://github.com/FoundationDB/fdb-record-layer/issues/1429) 2. Allow a range to be defined by the source index...
Currently, while a cumulative index is in write only mode, we keep track of the "already indexed" ranges and maintain the index iff the updated record is in one of...
This options seems to be dangerous and not very useful.
At some point, `OnlineIndexer.Builder.setIndexStatePrecondition` should be marked as deprecated.
Allow mutual concurrent multi target indexing