[
https://issues.apache.org/jira/browse/KAFKA-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sophie Blee-Goldman updated KAFKA-8159:
---------------------------------------
Description:
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.
was:
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.
> 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
(v7.6.3#76005)
