-
Notifications
You must be signed in to change notification settings - Fork 123
Description
The changes in v0.9.0 have broken CursorIterable for some KeyRange types and keys. I noticed the problem when using KeyRange.atLeastBackward(
. The cursor was starting on the wrong key.
I think the problem is this line:
It is using the standard java ByteBuffer.compareTo
method rather than your lexographical AbstractByteBufferProxy::compareBuff
method, so 150 is considered < 110.
See my branch (on the link below) where I have changed your CursorIterableTest
to use 200 ... 900 instead of 2 ... 9 for the key values to demonstrate the problem. With the modified values a lot of the tests fail. Changing AbstractByteBufferProxy
to use compareBuf
makes them all pass again.
https://github.com/lmdbjava/lmdbjava/compare/master...at055612:backwards-at-least?expand=1
I think this is the problem is in AbstractByteBufferProxy
.
@Override
protected Comparator<ByteBuffer> getComparator(final DbiFlags... flags) {
final int flagInt = mask(flags);
if (isSet(flagInt, MDB_INTEGERKEY)) {
return this::compareCustom;
}
return this::compareDefault;
// TODO Think the above line should be changed to this:
// return AbstractByteBufferProxy::compareBuff;
}
It may also be an issue for netty/agrona but I am not using those so have not looked.
This is a pretty serious bug for anyone using KeyRanges and it will present in subtle ways depending on the keys in the db and the keyRange type used.