-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix pagination for GetMultipleKeys, introducing startAfterKey #38
Conversation
@@ -30,7 +30,7 @@ class FossilDBSuite extends FlatSpec with BeforeAndAfterEach with TestHelpers wi | |||
private val testData3 = ByteString.copyFromUtf8("testData3") | |||
|
|||
private val aKey = "aKey" | |||
private val anotherKey = "anotherKey" | |||
private val aNotherKey = "aNotherKey" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this change to make the tests more intuitive (keys are alphabetically sorted now)
@@ -91,8 +93,6 @@ class VersionedKeyValueStore(underlying: RocksDBStore) { | |||
def get(key: String, version: Option[Long] = None): Option[VersionedKeyValuePair[Array[Byte]]] = | |||
scanVersionValuePairs(key, version).toStream.headOption | |||
|
|||
def getUnderlying: RocksDBStore = underlying |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was unused
@frcroth I know you are not familiar with this codebase yet, let’s have a talk about this in person (but feel free bo have a look already) |
Fixes a bug where the pagination for
GetMultipleKeys
could lead to an endless loop if some keys are prefixes of others.This happened because the scanKeys method would scan to the supplied start key, which the client would set to the last key of the previous response. However, if that key is a prefix of another key, that other key might come earlier in the sorted list, leading the scan operation to end up up there.
This is fixed by adding the version separator
@
to the start key before scanning to it. This ensures that prefix matches are not scanned to (since it can’t be a prefix if it includes the reserved character@
).However, that made it impossible to supply a start key that is not actually present. Since clients previously supplied the common prefix of the keys as the very first start key during pagination (because it was non-optional, but the clients don’t know the first actual key), they will not get the same results anymore. So I’d rather mark this as a breaking change, and while I’m on it, unify the pagination logic with ListKeys (introducing an optional startAfterKey instead of the ambiguous start key).
So the
GetMultipleKeys
call now takes astartAfterKey
instead of akey
for pagination. The returned list will only start after this key.I adapted the tests and added some more to ensure and document the functionality of GetMultipleKeys