Can you check if the problem exist for 0.10.2, too? (0.10.2 is compatible to 0.10.1 broker -- so you can upgrade your Streams code independently from the brokers).
About the range: I did double check this, and I guess my last answer was
not correct, and range() should return ordered data, but I got a follow
up question: what the key type and serializer you use? Internally, data
is stored in serialized form and ordered according to
`LexicographicByteArrayComparator` -- thus, if the serialized bytes
don't reflect the order of the deserialized data, it returned range
shows up unordered to you.
-Matthias
On 3/16/17 10:14 AM, Dmitry Minkovsky wrote:
> Hi Matthias. Thank you for your response.
>
> Yes, I was able to reproduce the null issue reliably. I can't open a JIRA
> at this time, but I can say I was using 0.10.1.0 and it was trivial to
> reproduce. Just send records and the tombstones to a table topic. Then scan
> the range. You'll see the tombstones.
>
> Indeed, ranges are returned with no specific order. I'm not sure what you
> mean that default stores are hash-based, but this ordering thing is a shame
> because it kind of kills the ability to use KS as a full fledged DB that
> lets you index things like HBase (composite keys for lists of items). Is
> that how RocksDB works? Just returns range scans in random order? I don't
> know C++ so the documentation is a bit opaque to me. But what's the point
> of scanning a range if the data comes in some random order? That being the
> case, the number of possible use-case scenarios seem to become
> significantly limited.
>
>
> Thank you!
> Dmitry
>
> On Tue, Mar 14, 2017 at 1:12 PM, Matthias J. Sax <matth...@confluent.io>
> wrote:
>
>>> However,
>>>> for keys that have been tombstoned, it does return null for me.
>>
>> Sound like a bug. Can you reliable reproduce this? Would you mind
>> opening a JIRA?
>>
>> Can you check if this happens for both cases: caching enabled and
>> disabled? Or only for once case?
>>
>>
>>> "No ordering guarantees are provided."
>>
>> That is correct. Internally, default stores are hash-based -- thus, we
>> don't give a sorted list/iterator back. You could replace RocksDB with a
>> custom store though.
>>
>>
>> -Matthias
>>
>>
>> On 3/13/17 3:56 PM, Dmitry Minkovsky wrote:
>>> I am using interactive streams to query tables:
>>>
>>> ReadOnlyKeyValueStore<Messages.ByUserAndDate,
>>> Messages.UserLetter> store
>>> = streams.store("view-user-drafts",
>>> QueryableStoreTypes.keyValueStore());
>>>
>>> Documentation says that #range() should not return null values. However,
>>> for keys that have been tombstoned, it does return null for me.
>>>
>>> Also, I noticed only just now that "No ordering guarantees are
>> provided." I
>>> haven't done enough testing or looked at the code carefully enough yet
>> and
>>> wonder if someone who knows could confirm: is this true? Is this common
>> to
>>> all store implementations? I was hoping to use interactive streams like
>>> HBase to scan ranges. It appears this is not possible.
>>>
>>> Thank you,
>>> Dmitry
>>>
>>
>>
>
signature.asc
Description: OpenPGP digital signature
