Boyang,
Thanks for your comment. The concern about whether a null-based approach
increases the chances of hidden bugs is a valid concern. In the end, the
decision to go with this approach was guided by considering the effort and
implications of changing the API towards a new range interface,
Thanks Patrick for the KIP and sorry for being late to the party here. One
thing I would like to understand is, what's the expected behavior when a
user specifies a null key in previous versions? In the new version which
uses null key for open-ended range queries, could it potentially hide bugs
in
Thanks John, Bruno for the valuable feedback!
John: I had a quick look at the SessionStore and WindowStore interface.
While it looks like we should be able to apply similar ideas to those
stores, the actual interfaces are slightly different and expanding them for
open ranges may need a bit more
Thanks for the KIP, Patrick!
I agree with John that your KIP is well motivated.
I have just one minor feedback. Could you add store.range(null, null) to
the example snippets with the comment that this is equivalent to all()
(it is equivalent, right?)? This question about equivalence between
Thanks for the KIP, Patrick!
I think your KIP is well motivated. It's definitely a bummer
to have to iterate over the full store as a workaround for
open-ended ranges.
I agree with your pragmatic approach here. We have recently
had a couple of other contributions to the store APIs
(prefix and
Hi everyone,
I would like to start the discussion for KIP-763: Range queries with open
endpoints.
The KIP can be found here:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-763%3A+Range+queries+with+open+endpoints
Any feedback will be highly appreciated.
Many thanks,
Patrick
