[
https://issues.apache.org/jira/browse/KAFKA-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803512#comment-16803512
]
Guozhang Wang commented on KAFKA-8159:
--------------------------------------
Thanks for reporting this. This is indeed an overlooked issue when looking at
integer serdes.
More generally speaking, today we are sorta assuming that all serdes used are
aligned with lexicographic ordering of bytes: if a typed object
A1.compareTo(A2) > 0, then their serialized bytes should have the same
relationaship lexicographically. However Integer / Long serdes etc definitely
does not obey this. So I'd suggest upgrading this ticket to this more broader
scope and use the multi-key range query as a specific observable issue of it.
> Multi-key range queries with negative keyFrom results in unexpected behavior
> ----------------------------------------------------------------------------
>
> 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
>
> If a user creates a queryable state store using one of the signed built-in
> serdes (eg Integer) for the key, there is nothing preventing records with
> negative keys from being inserted and/or fetched individually. However if the
> user tries to query the store for a range of keys starting with a negative
> number, unexpected behavior results that is store-specific.
>
> For RocksDB stores with caching disabled, an empty iterator will be returned.
> For in-memory stores and ANY store with caching enabled, Streams will throw
> an unchecked exception.
>
> This situation should be handled more gracefully, or users should be informed
> of this limitation and the result should at least be consist across types of
> store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
