Re: [VOTE] KIP-862: Self-join optimization for stream-stream joins
Hello everyone, The KIP-862 vote has passed with: binding +1s (John, Guozhang, Bruno) non-binding +1s (Jim) Thank you everyone for reviewing the KIP and voting. Best, Vicky On Fri, Sep 16, 2022 at 11:44 AM Bruno Cadonna wrote: > Hi Vicky, > > Thanks for the KIP! > > I think the KIP looks good! > You described how the self-join is optimized when the names of the state > stores are automatically generated by Streams. I think for completeness > you should also mention what happens when users explicitly name the > state stores of the self-join and give an example. > > For the rest, I am +1 (binding). > > Best, > Bruno > > > On 13.09.22 22:50, Jim Hughes wrote: > > Hi Vicky, > > > > I'm +1 (non-binding); thanks for the KIP (and PR)! > > > > Cheers, > > > > Jim > > > > On Tue, Sep 13, 2022 at 12:05 PM Guozhang Wang > wrote: > > > >> Thank Vicky! I'm +1. > >> > >> Guozhang > >> > >> On Mon, Sep 12, 2022 at 7:02 PM John Roesler > wrote: > >> > >>> Thanks for the updates, Vicky! > >>> > >>> I've reviewed the KIP and your POC PR, > >>> and I'm +1 (binding). > >>> > >>> Thanks! > >>> -John > >>> > >>> On Mon, Sep 12, 2022, at 09:13, Vasiliki Papavasileiou wrote: > >>>> Hey Guozhang, > >>>> > >>>> Great suggestion, I made the change. > >>>> > >>>> Best, > >>>> Vicky > >>>> > >>>> On Fri, Sep 9, 2022 at 10:43 PM Guozhang Wang > >>> wrote: > >>>> > >>>>> Thanks Vicky, that reads much clearer now. > >>>>> > >>>>> Just regarding the value string name itself: "self.join" may be > >>> confusing > >>>>> compared to other values that people would think before this config > is > >>>>> enabled, self-join are not allowed at all. Maybe we can rename it to > >>>>> "single.store.self.join"? > >>>>> > >>>>> Guozhang > >>>>> > >>>>> On Fri, Sep 9, 2022 at 2:15 AM Vasiliki Papavasileiou > >>>>> wrote: > >>>>> > >>>>>> Hey Guozhang, > >>>>>> > >>>>>> Ah it seems my text was not very clear :) > >>>>>> With "TOPOLOGY_OPTIMIZATION_CONFIG will be extended to accept a list > >>> of > >>>>>> optimization rule configs" I meant that it will accept the new value > >>>>>> strings for each optimization rule. Let me rephrase that in the KIP > >> to > >>>>> make > >>>>>> it clearer. > >>>>>> Is it better now? > >>>>>> > >>>>>> Best, > >>>>>> Vicky > >>>>>> > >>>>>> On Thu, Sep 8, 2022 at 9:07 PM Guozhang Wang > >>> wrote: > >>>>>> > >>>>>>> Thanks Vicky, > >>>>>>> > >>>>>>> I read through the KIP again and it looks good to me. Just a quick > >>>>>> question > >>>>>>> regarding the public config changes: you mentioned "No public > >>>>> interfaces > >>>>>>> will be impacted. The config TOPOLOGY_OPTIMIZATION_CONFIG will be > >>>>>> extended > >>>>>>> to accept a list of optimization rule configs in addition to the > >>> global > >>>>>>> values "all" and "none" . But there are no new value strings > >>> mentioned > >>>>> in > >>>>>>> this KIP, so that means we will apply this optimization only when > >>> `all` > >>>>>> is > >>>>>>> specified in the config right? > >>>>>>> > >>>>>>> > >>>>>>> Guozhang > >>>>>>> > >>>>>>> > >>>>>>> On Thu, Sep 8, 2022 at 12:02 PM Vasiliki Papavasileiou > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Hello everyone, > >>>>>>>> > >>>>>>>> I'd like to open the vote for KIP-862, which proposes to > >> optimize > >>>>>>>> stream-stream self-joins by using a single state store for the > >>> join. > >>>>>>>> > >>>>>>>> The proposal is here: > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>> > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-862%3A+Self-join+optimization+for+stream-stream+joins > >>>>>>>> > >>>>>>>> Thanks to all who reviewed the proposal, and thanks in advance > >> for > >>>>>> taking > >>>>>>>> the time to vote! > >>>>>>>> > >>>>>>>> Thank you, > >>>>>>>> Vicky > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> -- Guozhang > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> -- Guozhang > >>>>> > >>> > >> > >> > >> -- > >> -- Guozhang > >> > > >
Re: [VOTE] KIP-862: Self-join optimization for stream-stream joins
Hey Guozhang, Great suggestion, I made the change. Best, Vicky On Fri, Sep 9, 2022 at 10:43 PM Guozhang Wang wrote: > Thanks Vicky, that reads much clearer now. > > Just regarding the value string name itself: "self.join" may be confusing > compared to other values that people would think before this config is > enabled, self-join are not allowed at all. Maybe we can rename it to > "single.store.self.join"? > > Guozhang > > On Fri, Sep 9, 2022 at 2:15 AM Vasiliki Papavasileiou > wrote: > > > Hey Guozhang, > > > > Ah it seems my text was not very clear :) > > With "TOPOLOGY_OPTIMIZATION_CONFIG will be extended to accept a list of > > optimization rule configs" I meant that it will accept the new value > > strings for each optimization rule. Let me rephrase that in the KIP to > make > > it clearer. > > Is it better now? > > > > Best, > > Vicky > > > > On Thu, Sep 8, 2022 at 9:07 PM Guozhang Wang wrote: > > > > > Thanks Vicky, > > > > > > I read through the KIP again and it looks good to me. Just a quick > > question > > > regarding the public config changes: you mentioned "No public > interfaces > > > will be impacted. The config TOPOLOGY_OPTIMIZATION_CONFIG will be > > extended > > > to accept a list of optimization rule configs in addition to the global > > > values "all" and "none" . But there are no new value strings mentioned > in > > > this KIP, so that means we will apply this optimization only when `all` > > is > > > specified in the config right? > > > > > > > > > Guozhang > > > > > > > > > On Thu, Sep 8, 2022 at 12:02 PM Vasiliki Papavasileiou > > > wrote: > > > > > > > Hello everyone, > > > > > > > > I'd like to open the vote for KIP-862, which proposes to optimize > > > > stream-stream self-joins by using a single state store for the join. > > > > > > > > The proposal is here: > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-862%3A+Self-join+optimization+for+stream-stream+joins > > > > > > > > Thanks to all who reviewed the proposal, and thanks in advance for > > taking > > > > the time to vote! > > > > > > > > Thank you, > > > > Vicky > > > > > > > > > > > > > -- > > > -- Guozhang > > > > > > > > -- > -- Guozhang >
Re: [VOTE] KIP-862: Self-join optimization for stream-stream joins
Hey Guozhang, Ah it seems my text was not very clear :) With "TOPOLOGY_OPTIMIZATION_CONFIG will be extended to accept a list of optimization rule configs" I meant that it will accept the new value strings for each optimization rule. Let me rephrase that in the KIP to make it clearer. Is it better now? Best, Vicky On Thu, Sep 8, 2022 at 9:07 PM Guozhang Wang wrote: > Thanks Vicky, > > I read through the KIP again and it looks good to me. Just a quick question > regarding the public config changes: you mentioned "No public interfaces > will be impacted. The config TOPOLOGY_OPTIMIZATION_CONFIG will be extended > to accept a list of optimization rule configs in addition to the global > values "all" and "none" . But there are no new value strings mentioned in > this KIP, so that means we will apply this optimization only when `all` is > specified in the config right? > > > Guozhang > > > On Thu, Sep 8, 2022 at 12:02 PM Vasiliki Papavasileiou > wrote: > > > Hello everyone, > > > > I'd like to open the vote for KIP-862, which proposes to optimize > > stream-stream self-joins by using a single state store for the join. > > > > The proposal is here: > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-862%3A+Self-join+optimization+for+stream-stream+joins > > > > Thanks to all who reviewed the proposal, and thanks in advance for taking > > the time to vote! > > > > Thank you, > > Vicky > > > > > -- > -- Guozhang >
[VOTE] KIP-862: Self-join optimization for stream-stream joins
Hello everyone, I'd like to open the vote for KIP-862, which proposes to optimize stream-stream self-joins by using a single state store for the join. The proposal is here: https://cwiki.apache.org/confluence/display/KAFKA/KIP-862%3A+Self-join+optimization+for+stream-stream+joins Thanks to all who reviewed the proposal, and thanks in advance for taking the time to vote! Thank you, Vicky
Re: [DISCUSS] KIP-862: Implement self-join optimization
Hi Guozhang, That's an excellent idea, I will make the changes. I was also going back and forth with having a specific config for each optimization or not but I feel your approach has the best of both worlds. Thank you, Vicky On Sun, Aug 28, 2022 at 6:20 AM Guozhang Wang wrote: > Hello Vicky, > > I made a quick pass on your WIP PR and now I understand and agree that > compatibility is indeed preserved since we get the optimized topology in a > second pass, and hence we already "used and burned" the original topologies > naming suffices in the first pass. > > Regarding the configuration patterns, I still have a bit concern about it: > primarily, if we follow this pattern to introduce a new config for each > optimization rule, in the future we would have a lot of configs --- one per > rule --- inside the StreamsConfig. I thought about this back and forth > again and still feel that this may not be what we want.. I think stead, we > can change the existing `TOPOLOGY_OPTIMIZATION_CONFIG` to accept a list of > strings, separated by comma --- this aligns with other similar configs as > well --- so that for different scenarios users can choose either fine > grained or coarse grained controls, e.g.: > > * I just want to enable all rules, or none: "all", "none". > * I know my app was created with Kafka version X, and I just want to only > apply all rules that are already there since version X: "versionX" --- I > just made it up for future use cases since we discussed about it in the > original KIP when we introduced "TOPOLOGY_OPTIMIZATION_CONFIG", we do not > need to include it in this KIP. > * I know my app is compatible with specific rules A/B/C, and I just want to > always enable those and not others: "ruleA,ruleB,ruleC". > > SO far we only have a few rules: a) reuse source topic as changelog topic > for KTable, b) merge duplicate repartition topics, c) self-join (this KIP), > so I suggest in this KIP, we just add make the > `TOPOLOGY_OPTIMIZATION_CONFIG` accepting a list of string, but 1) check > that some strings cannot coexist (e.g. `none` and all`), and 2) add a new > string value for self-join itself. In this way: > > * People who chose `none` before will not be impacted. > * People who chose `all` before will get this optimization by default, and > it's backward compatible so it's okay; they also get what they meant: I > just want "all" :) > * Advanced users who read about this KIP and just what it but not others: > they will change their config from `none` to `self-join`. > > WDYT? > > > Guozhang > > > > > On Fri, Aug 12, 2022 at 7:25 PM John Roesler wrote: > > > Thanks for the KIP, Vicky! > > > > Re 1/2, I agree with what you both worked out. > > > > Re 3: It sounds like you were able to preserve backward compatibility, so > > I don’t think you need to add any new configs. I think you can just > switch > > it on if people specify “all”. > > > > Thanks! > > -John > > > > > > On Thu, Aug 11, 2022, at 11:27, Guozhang Wang wrote: > > > Thanks Vicky for your reply! > > > > > > Re 1/2): I think you have a great point here to adhere with the > existing > > > implementation, I'm convinced. In that case we do not need to consider > > > left/outer-joins, and hence do not need to worry about the extra store > in > > > the impl. > > > > > > Re 3): I'm curious how the compatibility is preserved since with > > > optimizations turned on, we would use fewer stores and hence the store > > name > > > suffixes would change. In your experiment did you specifically specify > > the > > > store names, e.g. via Materialized? I'd be glad if it turns out to > really > > > be conveniently backward compatible, and rest with my concerns :) > > > > > > > > > Guozhang > > > > > > On Thu, Aug 11, 2022 at 4:44 AM Vasiliki Papavasileiou > > > wrote: > > > > > >> Hi Guozhang, > > >> > > >> Thank you very much for your comments. > > >> > > >> Regarding 1: the extra state store is only needed in outer joins since > > >> that's the only case we have non-joining records that would need to > get > > >> emitted when the window closes, right? If we do decide to go with an > > >> outer-join implementation, I will make sure to have the extra state > > store > > >> as well. Thank you for pointing it out. > > >> > > >> Regarding 2: As the self-join is only a physical optimization over an > > inner > > >
Re: [DISCUSS] KIP-862: Implement self-join optimization
names) should not change -- when we use suffixes, we > should make sure they do not change by burning some suffixes as well, b) > the processor names, similar to store names, c) store formats, if we ever > change the store formats, we need to consider a live upgrade path as well. > > Please let me know your thoughts. > > Guozhang > > > On Tue, Aug 2, 2022 at 11:31 AM Vasiliki Papavasileiou > wrote: > > > Hello everyone, > > > > I would like to start the discussion for KIP-862: Implement self-join > > optimization > > > > The KIP can be found here: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-862%3A+Self-join > > > > Any suggestions are more than welcome. > > > > Many thanks, > > Vicky > > > > > -- > -- Guozhang >
[DISCUSS] KIP-862: Implement self-join optimization
Hello everyone, I would like to start the discussion for KIP-862: Implement self-join optimization The KIP can be found here: https://cwiki.apache.org/confluence/display/KAFKA/KIP-862%3A+Self-join Any suggestions are more than welcome. Many thanks, Vicky
Re: [VOTE] KIP-805: Add range and scan query support in IQ v2
Hello everyone, Thank you for the discussion and for voting. The vote on KIP-805 passes with: 3 binding +1 (John, Matthias, and Guozhang), 1 non-binding +1 (Luke), no vetoes. The vote is now closed. If anyone has objections later on, please don't hesitate to let me know. I will proceed with implementing the PR for the queries. Thank you, Vicky On Mon, Dec 13, 2021 at 10:49 AM Vasiliki Papavasileiou < vpapavasile...@confluent.io> wrote: > Hello everyone, > > Thank you for your comments. I applied the changes. > Hope things are clearer now. > > Best, > Vicky > > On Mon, Dec 13, 2021 at 8:24 AM Luke Chen wrote: > >> Hi Vicky, >> >> I checked the KIP again, and found there's something you might need to >> have >> some description. >> The term: *scan query*, is my first time seeing this term. >> I think it's not a publicly known term (or it's just me?), and might need >> some description for it. >> And for the "range query", I think you can also have some words for it. >> >> Thank you. >> Luke >> >> On Sat, Dec 11, 2021 at 2:26 AM Guozhang Wang wrote: >> >> > Thanks Vicky, >> > >> > I'd suggest we change the KIP title as "add range and scan query over >> > kv-store in IQv2" just for clarification, otherwise I'm +1. >> > >> > Guozhang >> > >> > On Wed, Dec 8, 2021 at 4:18 PM Matthias J. Sax >> wrote: >> > >> > > Thanks for the KIP. >> > > >> > > +1 (binding) >> > > >> > > On 12/5/21 7:03 PM, Luke Chen wrote: >> > > > Hi Vasiliki, >> > > > >> > > > Thanks for the KIP! >> > > > It makes sense to have the range and scan query in IQv2, as in IQv1. >> > > > >> > > > +1 (non-binding) >> > > > >> > > > Thank you. >> > > > Luke >> > > > >> > > > On Thu, Dec 2, 2021 at 5:41 AM John Roesler >> > wrote: >> > > > >> > > >> Thanks for the KIP, Vicky! >> > > >> >> > > >> I’m +1 (binding) >> > > >> >> > > >> -John >> > > >> >> > > >> On Tue, Nov 30, 2021, at 14:51, Vasiliki Papavasileiou wrote: >> > > >>> Hello everyone, >> > > >>> >> > > >>> I would like to start a vote for KIP-805 that adds range and scan >> > > >> KeyValue >> > > >>> queries in IQ2. >> > > >>> >> > > >>> The KIP can be found here: >> > > >>> >> > > >> >> > > >> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-805%3A+Add+range+and+scan+query+support+in+IQ+v2 >> > > >>> >> > > >>> Cheers! >> > > >>> Vicky >> > > >> >> > > > >> > > >> > >> > >> > -- >> > -- Guozhang >> > >> >
Re: [VOTE] KIP-805: Add range and scan query support in IQ v2
Hello everyone, Thank you for your comments. I applied the changes. Hope things are clearer now. Best, Vicky On Mon, Dec 13, 2021 at 8:24 AM Luke Chen wrote: > Hi Vicky, > > I checked the KIP again, and found there's something you might need to have > some description. > The term: *scan query*, is my first time seeing this term. > I think it's not a publicly known term (or it's just me?), and might need > some description for it. > And for the "range query", I think you can also have some words for it. > > Thank you. > Luke > > On Sat, Dec 11, 2021 at 2:26 AM Guozhang Wang wrote: > > > Thanks Vicky, > > > > I'd suggest we change the KIP title as "add range and scan query over > > kv-store in IQv2" just for clarification, otherwise I'm +1. > > > > Guozhang > > > > On Wed, Dec 8, 2021 at 4:18 PM Matthias J. Sax wrote: > > > > > Thanks for the KIP. > > > > > > +1 (binding) > > > > > > On 12/5/21 7:03 PM, Luke Chen wrote: > > > > Hi Vasiliki, > > > > > > > > Thanks for the KIP! > > > > It makes sense to have the range and scan query in IQv2, as in IQv1. > > > > > > > > +1 (non-binding) > > > > > > > > Thank you. > > > > Luke > > > > > > > > On Thu, Dec 2, 2021 at 5:41 AM John Roesler > > wrote: > > > > > > > >> Thanks for the KIP, Vicky! > > > >> > > > >> I’m +1 (binding) > > > >> > > > >> -John > > > >> > > > >> On Tue, Nov 30, 2021, at 14:51, Vasiliki Papavasileiou wrote: > > > >>> Hello everyone, > > > >>> > > > >>> I would like to start a vote for KIP-805 that adds range and scan > > > >> KeyValue > > > >>> queries in IQ2. > > > >>> > > > >>> The KIP can be found here: > > > >>> > > > >> > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-805%3A+Add+range+and+scan+query+support+in+IQ+v2 > > > >>> > > > >>> Cheers! > > > >>> Vicky > > > >> > > > > > > > > > > > > > -- > > -- Guozhang > > >
Re: [DISCUSS] KIP-805: Add range and scan query support in IQ v2
Hey Guozhang, Thank you for looking into the KIP. Windowed stores are addressed in another KIP. FYI, I made a change to the KIP and removed the `RawRangeQuery`. After some more thought, it doesn't provide us with many benefits (we save on one cast) which doesn't justify the cost of adding an extra query to the public interface. On Thu, Dec 9, 2021 at 9:50 PM Guozhang Wang wrote: > Hi Vicky, > > Thanks for the KIP. Just for a bit more clarification, could you elaborate > an example for windowed stores, beyond a key-value store (I think the > `myStore` is for kv-store right?). Otherwise LGTM. > > > Guozhang > > On Wed, Dec 8, 2021 at 4:18 PM Matthias J. Sax wrote: > > > Thanks for the details! > > > > I also chatted with John about it, and he filed > > https://issues.apache.org/jira/browse/KAFKA-13526 to incorporate some > > feedback as follow up work. > > > > IMHO, the hard coded query translation is not ideal and should be > > plugable. But for a v1 of IQv2 (pun intended) the hardcoded translation > > seems to be good enough. > > > > > > -Matthias > > > > On 12/8/21 9:37 AM, Vasiliki Papavasileiou wrote: > > > Hey Matthias, > > > > > > Thank you for looking into the KIP! > > > > > > We are adding raw versions of typed queries, like `RawRangeQuery` > because > > > it simplifies internal query handling since the bytes stores only > support > > > raw queries. A typed RangeQuery is handled by the `MeteredStore` which > > > creates a new `RawRangeQuery` to pass down to the wrapped stores. When > it > > > gets the result back, it deserializes the data and creates a typed > query > > > result to return to the user. So, the store's key serde are used to > > > translate typed `RangeQueries` into `RawRangeQueries` and it's value > > serde > > > are used to translate the result of the query on the way back. This > > allows > > > users to provide their own queries even if the MeteredStore has no > > > knowledge of them. > > > > > > I hope this answers your question. Let me know if you have any other > > > questions. > > > > > > Best, > > > Vicky > > > > > > > > > On Tue, Dec 7, 2021 at 12:46 AM Matthias J. Sax > > wrote: > > > > > >> Thanks for the KIP. Overall, make sense. > > >> > > >> One question: What is the purpose to `RawRangeQuery`? Seems not very > > >> user friendly. > > >> > > >> -Matthias > > >> > > >> > > >> On 11/30/21 12:48 PM, Vasiliki Papavasileiou wrote: > > >>> Thank you John! Yes, that was a typo from copying and I fixed it. > > >>> > > >>> Since there have been no more comments, I will start the vote. > > >>> > > >>> Best, > > >>> Vicky > > >>> > > >>> On Tue, Nov 30, 2021 at 5:22 AM John Roesler > > >> wrote: > > >>> > > >>>> Thanks for the KIP, Vicky! > > >>>> > > >>>> This KIP will help fill in the parity gap between IQ and > > >>>> IQv2. > > >>>> > > >>>> One thing I noticed, which looks like just a typo is that > > >>>> the value type of the proposed RangeQuery should probably be > > >>>> KeyValueIterator, right? > > >>>> > > >>>> Otherwise, it looks good to me! > > >>>> > > >>>> Thanks, > > >>>> -John > > >>>> > > >>>> On Mon, 2021-11-29 at 12:20 +, Vasiliki Papavasileiou > > >>>> wrote: > > >>>>> Hello everyone, > > >>>>> > > >>>>> I would like to start the discussion for KIP-805: Add range and > scan > > >>>> query > > >>>>> support in IQ v2 > > >>>>> > > >>>>> The KIP can be found here: > > >>>>> > > >>>> > > >> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-805%3A+Add+range+and+scan+query+support+in+IQ+v2 > > >>>>> > > >>>>> Any suggestions are more than welcome. > > >>>>> > > >>>>> Many thanks, > > >>>>> Vicky > > >>>> > > >>>> > > >>> > > >> > > > > > > > > -- > -- Guozhang >
Re: [DISCUSS] KIP-805: Add range and scan query support in IQ v2
Hey Matthias, Thank you for looking into the KIP! We are adding raw versions of typed queries, like `RawRangeQuery` because it simplifies internal query handling since the bytes stores only support raw queries. A typed RangeQuery is handled by the `MeteredStore` which creates a new `RawRangeQuery` to pass down to the wrapped stores. When it gets the result back, it deserializes the data and creates a typed query result to return to the user. So, the store's key serde are used to translate typed `RangeQueries` into `RawRangeQueries` and it's value serde are used to translate the result of the query on the way back. This allows users to provide their own queries even if the MeteredStore has no knowledge of them. I hope this answers your question. Let me know if you have any other questions. Best, Vicky On Tue, Dec 7, 2021 at 12:46 AM Matthias J. Sax wrote: > Thanks for the KIP. Overall, make sense. > > One question: What is the purpose to `RawRangeQuery`? Seems not very > user friendly. > > -Matthias > > > On 11/30/21 12:48 PM, Vasiliki Papavasileiou wrote: > > Thank you John! Yes, that was a typo from copying and I fixed it. > > > > Since there have been no more comments, I will start the vote. > > > > Best, > > Vicky > > > > On Tue, Nov 30, 2021 at 5:22 AM John Roesler > wrote: > > > >> Thanks for the KIP, Vicky! > >> > >> This KIP will help fill in the parity gap between IQ and > >> IQv2. > >> > >> One thing I noticed, which looks like just a typo is that > >> the value type of the proposed RangeQuery should probably be > >> KeyValueIterator, right? > >> > >> Otherwise, it looks good to me! > >> > >> Thanks, > >> -John > >> > >> On Mon, 2021-11-29 at 12:20 +, Vasiliki Papavasileiou > >> wrote: > >>> Hello everyone, > >>> > >>> I would like to start the discussion for KIP-805: Add range and scan > >> query > >>> support in IQ v2 > >>> > >>> The KIP can be found here: > >>> > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-805%3A+Add+range+and+scan+query+support+in+IQ+v2 > >>> > >>> Any suggestions are more than welcome. > >>> > >>> Many thanks, > >>> Vicky > >> > >> > > >
[VOTE] KIP-805: Add range and scan query support in IQ v2
Hello everyone, I would like to start a vote for KIP-805 that adds range and scan KeyValue queries in IQ2. The KIP can be found here: https://cwiki.apache.org/confluence/display/KAFKA/KIP-805%3A+Add+range+and+scan+query+support+in+IQ+v2 Cheers! Vicky
Re: [DISCUSS] KIP-805: Add range and scan query support in IQ v2
Thank you John! Yes, that was a typo from copying and I fixed it. Since there have been no more comments, I will start the vote. Best, Vicky On Tue, Nov 30, 2021 at 5:22 AM John Roesler wrote: > Thanks for the KIP, Vicky! > > This KIP will help fill in the parity gap between IQ and > IQv2. > > One thing I noticed, which looks like just a typo is that > the value type of the proposed RangeQuery should probably be > KeyValueIterator, right? > > Otherwise, it looks good to me! > > Thanks, > -John > > On Mon, 2021-11-29 at 12:20 +, Vasiliki Papavasileiou > wrote: > > Hello everyone, > > > > I would like to start the discussion for KIP-805: Add range and scan > query > > support in IQ v2 > > > > The KIP can be found here: > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-805%3A+Add+range+and+scan+query+support+in+IQ+v2 > > > > Any suggestions are more than welcome. > > > > Many thanks, > > Vicky > >
[DISCUSS] KIP-805: Add range and scan query support in IQ v2
Hello everyone, I would like to start the discussion for KIP-805: Add range and scan query support in IQ v2 The KIP can be found here: https://cwiki.apache.org/confluence/display/KAFKA/KIP-805%3A+Add+range+and+scan+query+support+in+IQ+v2 Any suggestions are more than welcome. Many thanks, Vicky
Re: [VOTE} KIP-796: Interactive Query v2
I think this KIP will greatly improve how we handle IQ in streams so +1 (non-binding) from me. Thank you John! On Thu, Nov 18, 2021 at 9:45 PM Patrick Stuedi wrote: > +1 (non-binding), thanks John! > -Patrick > > On Thu, Nov 18, 2021 at 12:27 AM John Roesler wrote: > > > Hello all, > > > > I'd like to open the vote for KIP-796, which proposes > > a revamp of the Interactive Query APIs in Kafka Streams. > > > > The proposal is here: > > https://cwiki.apache.org/confluence/x/34xnCw > > > > Thanks to all who reviewed the proposal, and thanks in > > advance for taking the time to vote! > > > > Thank you, > > -John > > >
Re: [VOTE] KIP-791: Add Record Metadata to State Store Context
Hi Patrick, Having the recordMetadata available in the state stores is fundamental for the consistency work and the proposed approach is reasonable. +1 (non-binding) Thank you, Vicky On Mon, Nov 8, 2021 at 10:00 AM Luke Chen wrote: > Hi Patrick, > Thanks for the KIP. > Adding RecordMetadata into StateStoreContext for offset updating makes > sense to me. > > +1 (non-binding) > > Thank you. > Luke > > > On Mon, Nov 8, 2021 at 5:18 PM Patrick Stuedi > > wrote: > > > Hi all, > > > > Thanks for the feedback on KIP-791, I have updated the KIP and would like > > to start the voting. > > > > The KIP can be found here: > > https://cwiki.apache.org/confluence/x/I5BnCw > > > > Please vote in this thread. > > > > Thanks! > > -Patrick > > >
Permissions to contribute to Apache Kafka
Wiki ID: vicky_papavas Jira ID: vicky_papavas
