Hi Bill,
1. I will update the KIP in accordance with the PR and synchronize their
future updates.
2. I will use that name.
3. you mean add something about ordering at the motivation section?

Sincerely,
Hanyu


On Tue, Oct 3, 2023 at 4:29 PM Hanyu (Peter) Zheng <pzh...@confluent.io>
wrote:

> Hi, Walker,
>
> 1. I will update the KIP in accordance with the PR and synchronize their
> future updates.
> 2. I will use that name.
> 3. I'll provide additional details in that section.
> 4. I intend to utilize rangeQuery to achieve what we're referring to as
> reverseQuery. In essence, reverseQuery is merely a term. To clear up any
> ambiguity, I'll make necessary adjustments to the KIP.
>
> Sincerely,
> Hanyu
>
>
>
> On Tue, Oct 3, 2023 at 4:09 PM Hanyu (Peter) Zheng <pzh...@confluent.io>
> wrote:
>
>> Ok, I will change it back to following the code, and update them
>> together.
>>
>> On Tue, Oct 3, 2023 at 2:27 PM Walker Carlson
>> <wcarl...@confluent.io.invalid> wrote:
>>
>>> Hello Hanyu,
>>>
>>> Looking over your kip things mostly make sense but I have a couple of
>>> comments.
>>>
>>>
>>>    1. You have "withDescandingOrder()". I think you mean "descending" :)
>>>    Also there are still a few places in the do where its called
>>> "setReverse"
>>>    2. Also I like "WithDescendingKeys()" better
>>>    3. I'm not sure of what ordering guarantees we are offering. Perhaps
>>> we
>>>    can add a section to the motivation clearly spelling out the current
>>>    ordering and the new offering?
>>>    4. When you say "use unbounded reverseQuery to achieve reverseAll" do
>>>    you mean "use unbounded RangeQuery to achieve reverseAll"? as far as
>>> I can
>>>    tell we don't have a reverseQuery as a named object?
>>>
>>>
>>> Looking good so far
>>>
>>> best,
>>> Walker
>>>
>>> On Tue, Oct 3, 2023 at 2:13 PM Colt McNealy <c...@littlehorse.io> wrote:
>>>
>>> > Hello Hanyu,
>>> >
>>> > Thank you for the KIP. I agree with Matthias' proposal to keep the
>>> naming
>>> > convention consistent with KIP-969. I favor the `.withDescendingKeys()`
>>> > name.
>>> >
>>> > I am curious about one thing. RocksDB guarantees that records returned
>>> > during a range scan are lexicographically ordered by the bytes of the
>>> keys
>>> > (either ascending or descending order, as specified in the query). This
>>> > means that results within a single partition are indeed ordered.** My
>>> > reading of KIP-805 suggests to me that you don't need to specify the
>>> > partition number you are querying in IQv2, which means that you can
>>> have a
>>> > valid reversed RangeQuery over a store with "multiple partitions" in
>>> it.
>>> >
>>> > Currently, IQv1 does not guarantee order of keys in this scenario. Does
>>> > IQv2 support ordering across partitions? Such an implementation would
>>> > require opening a rocksdb range scan** on multiple rocksdb instances
>>> (one
>>> > per partition), and polling the first key of each. Whether or not this
>>> is
>>> > ordered, could we please add that to the documentation?
>>> >
>>> > **(How is this implemented/guaranteed in an `inMemoryKeyValueStore`? I
>>> > don't know about that implementation).
>>> >
>>> > Colt McNealy
>>> >
>>> > *Founder, LittleHorse.dev*
>>> >
>>> >
>>> > On Tue, Oct 3, 2023 at 1:35 PM Hanyu (Peter) Zheng
>>> > <pzh...@confluent.io.invalid> wrote:
>>> >
>>> > > ok, I will update it. Thank you  Matthias
>>> > >
>>> > > Sincerely,
>>> > > Hanyu
>>> > >
>>> > > On Tue, Oct 3, 2023 at 11:23 AM Matthias J. Sax <mj...@apache.org>
>>> > wrote:
>>> > >
>>> > > > Thanks for the KIP Hanyu!
>>> > > >
>>> > > >
>>> > > > I took a quick look and it think the proposal makes sense overall.
>>> > > >
>>> > > > A few comments about how to structure the KIP.
>>> > > >
>>> > > > As you propose to not add `ReverseRangQuery` class, the code
>>> example
>>> > > > should go into "Rejected Alternatives" section, not in the
>>> "Proposed
>>> > > > Changes" section.
>>> > > >
>>> > > > For the `RangeQuery` code example, please omit all existing methods
>>> > etc,
>>> > > > and only include what will be added/changed. This make it simpler
>>> to
>>> > > > read the KIP.
>>> > > >
>>> > > >
>>> > > > nit: typo
>>> > > >
>>> > > > >  the fault value is false
>>> > > >
>>> > > > Should be "the default value is false".
>>> > > >
>>> > > >
>>> > > > Not sure if `setReverse()` is the best name. Maybe
>>> > `withDescandingOrder`
>>> > > > (or similar, I guess `withReverseOrder` would also work) might be
>>> > > > better? Would be good to align to KIP-969 proposal that suggest do
>>> use
>>> > > > `withDescendingKeys` methods for "reverse key-range"; if we go with
>>> > > > `withReverseOrder` we should change KIP-969 accordingly.
>>> > > >
>>> > > > Curious to hear what others think about naming this consistently
>>> across
>>> > > > both KIPs.
>>> > > >
>>> > > >
>>> > > > -Matthias
>>> > > >
>>> > > >
>>> > > > On 10/3/23 9:17 AM, Hanyu (Peter) Zheng wrote:
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-985%3A+Add+reverseRange+and+reverseAll+query+over+kv-store+in+IQv2
>>> > > > >
>>> > > >
>>> > >
>>> > >
>>> > > --
>>> > >
>>> > > [image: Confluent] <https://www.confluent.io>
>>> > > Hanyu (Peter) Zheng he/him/his
>>> > > Software Engineer Intern
>>> > > +1 (213) 431-7193 <+1+(213)+431-7193>
>>> > > Follow us: [image: Blog]
>>> > > <
>>> > >
>>> >
>>> https://www.confluent.io/blog?utm_source=footer&utm_medium=email&utm_campaign=ch.email-signature_type.community_content.blog
>>> > > >[image:
>>> > > Twitter] <https://twitter.com/ConfluentInc>[image: LinkedIn]
>>> > > <https://www.linkedin.com/in/hanyu-peter-zheng/>[image: Slack]
>>> > > <https://slackpass.io/confluentcommunity>[image: YouTube]
>>> > > <https://youtube.com/confluent>
>>> > >
>>> > > [image: Try Confluent Cloud for Free]
>>> > > <
>>> > >
>>> >
>>> https://www.confluent.io/get-started?utm_campaign=tm.fm-apac_cd.inbound&utm_source=gmail&utm_medium=organic
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>> --
>>
>> [image: Confluent] <https://www.confluent.io>
>> Hanyu (Peter) Zheng he/him/his
>> Software Engineer Intern
>> +1 (213) 431-7193 <+1+(213)+431-7193>
>> Follow us: [image: Blog]
>> <https://www.confluent.io/blog?utm_source=footer&utm_medium=email&utm_campaign=ch.email-signature_type.community_content.blog>[image:
>> Twitter] <https://twitter.com/ConfluentInc>[image: LinkedIn]
>> <https://www.linkedin.com/in/hanyu-peter-zheng/>[image: Slack]
>> <https://slackpass.io/confluentcommunity>[image: YouTube]
>> <https://youtube.com/confluent>
>>
>> [image: Try Confluent Cloud for Free]
>> <https://www.confluent.io/get-started?utm_campaign=tm.fm-apac_cd.inbound&utm_source=gmail&utm_medium=organic>
>>
>
>
> --
>
> [image: Confluent] <https://www.confluent.io>
> Hanyu (Peter) Zheng he/him/his
> Software Engineer Intern
> +1 (213) 431-7193 <+1+(213)+431-7193>
> Follow us: [image: Blog]
> <https://www.confluent.io/blog?utm_source=footer&utm_medium=email&utm_campaign=ch.email-signature_type.community_content.blog>[image:
> Twitter] <https://twitter.com/ConfluentInc>[image: LinkedIn]
> <https://www.linkedin.com/in/hanyu-peter-zheng/>[image: Slack]
> <https://slackpass.io/confluentcommunity>[image: YouTube]
> <https://youtube.com/confluent>
>
> [image: Try Confluent Cloud for Free]
> <https://www.confluent.io/get-started?utm_campaign=tm.fm-apac_cd.inbound&utm_source=gmail&utm_medium=organic>
>


-- 

[image: Confluent] <https://www.confluent.io>
Hanyu (Peter) Zheng he/him/his
Software Engineer Intern
+1 (213) 431-7193 <+1+(213)+431-7193>
Follow us: [image: Blog]
<https://www.confluent.io/blog?utm_source=footer&utm_medium=email&utm_campaign=ch.email-signature_type.community_content.blog>[image:
Twitter] <https://twitter.com/ConfluentInc>[image: LinkedIn]
<https://www.linkedin.com/in/hanyu-peter-zheng/>[image: Slack]
<https://slackpass.io/confluentcommunity>[image: YouTube]
<https://youtube.com/confluent>

[image: Try Confluent Cloud for Free]
<https://www.confluent.io/get-started?utm_campaign=tm.fm-apac_cd.inbound&utm_source=gmail&utm_medium=organic>

Reply via email to