ableegoldman commented on a change in pull request #10052:
URL: https://github.com/apache/kafka/pull/10052#discussion_r577140223
##########
File path:
streams/src/test/java/org/apache/kafka/streams/state/internals/InMemoryKeyValueStoreTest.java
##########
@@ -60,4 +67,22 @@ public void shouldRemoveKeysWithNullValues() {
assertThat(store.get(0), nullValue());
}
+
+
+ @Test
+ public void shouldReturnKeysWithGivenPrefix(){
+ store = createKeyValueStore(driver.context());
+ final String value = "value";
+ final List<KeyValue<Integer, String>> entries = new ArrayList<>();
+ entries.add(new KeyValue<>(1, value));
+ entries.add(new KeyValue<>(2, value));
+ entries.add(new KeyValue<>(11, value));
+ entries.add(new KeyValue<>(13, value));
+
+ store.putAll(entries);
+ final KeyValueIterator<Integer, String> keysWithPrefix =
store.prefixScan(1, new IntegerSerializer());
Review comment:
Yeah, the underlying store compares the serializer bytes
lexicographically, it doesn't have any concept of "Integer" or any other type.
And the really tricky thing is that it scans lexicographically, which means
from left to right, whereas when we serialize things we usually do so from
right to left. eg `2` in binary is `10` whereas 11 in binary is `1011` and 13
is `1101`.
The problem here is that the serialized version of 2 is a different number
of bytes than the serialized form of 11/13, so the lexicographical comparator
is effectively comparing digits of a different magnitude.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
