fdb-record-layer
fdb-record-layer copied to clipboard
A record-oriented store built on FoundationDB
Create a mock store that can use mock data to simulate a store for testing purposes without FDB running. This can be used for feature testing with mock data but...
At the moment, when a single record is deleted, we (typically) will end up issuing one range delete that covers the whole record. See this implementation in `KeyValueUnsplitter`: https://github.com/FoundationDB/fdb-record-layer/blob/ceaaeb538d3328ad6e3b32f03c34c3764a0195b6/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/provider/foundationdb/SplitHelper.java#L239-L250 Note...
I tried to follow the documentation to build DFB-RL and run some tests on a fresh environment, I noticed that the provided command in step 2 in the documentation: `./gradlew...
Currently `Comparison` does not implement `Correlated`. That means that even `ParameterComparison` is not considered to be correlated to anything. There is usage for a `ParameterComparison` which can be a correlation...
FDB version 6.3 has introduced this new feature called multi-threaded client and seems like the record layer has added support for it. [link](https://github.com/FoundationDB/fdb-record-layer/blob/main/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/provider/foundationdb/FDBDatabaseFactoryImpl.java#L143) However, when I was reading through the...
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.