[
https://issues.apache.org/jira/browse/KAFKA-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169187#comment-17169187
]
Sophie Blee-Goldman commented on KAFKA-8159:
--------------------------------------------
A related bummer is that you can't do fetches over a range of positive and
negative timestamps in a Window/Session store (well you can, you just won't get
the behavior you'd expect)
I say "related" because we don't use the built-in serdes to serialize the long
in a windowed key, we use ByteBuffer#putLong. But it has the same problem with
our lexicographical bytes
> Built-in serdes for signed numbers do not obey lexicographical ordering
> -----------------------------------------------------------------------
>
> Key: KAFKA-8159
> URL: https://issues.apache.org/jira/browse/KAFKA-8159
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Reporter: Sophie Blee-Goldman
> Priority: Major
>
> Currently we assume consistent ordering between serialized and deserialized
> keys, e.g. if the objects obey objA < objB < objC then the serialized Bytes
> will also obey bytesA < bytesB < bytesC. This is not true in general of the
> built-in serdes for signed numerical types (eg Integer, Long). Specifically,
> it is broken by the negative number representations which are
> lexicographically greater than (all) positive number representations.
>
> One consequence of this is that an interactive query of a key range with a
> negative lower bound and positive upper bound (eg keyValueStore.range(-1, 1)
> will result in "unexpected behavior" depending on the specific store type.
>
> For RocksDB stores with caching disabled, an empty iterator will be returned
> regardless of whether any records do exist in that range.
> For in-memory stores and ANY store with caching enabled, Streams will throw
> an unchecked exception and crash.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
