Thanks, all. This all sounds good to me. I’ll send a PR to add a warning/disclaimer to the javadoc. I don’t believe we updated the docs yet, but I will double-check.
Thanks, John On Tue, Mar 22, 2022, at 20:06, Matthias J. Sax wrote: > The old API IQv1 is not deprecated yet, so I don't see a reason to revert. > > We might not want to "advertise" the IQv2 in the release announcement > though if it's not complete and unstable right now. > > We might also not want to mention it in the docs? Not sure if there was > already docs PR. If yes, reverting the docs or adding a BIG disclaimer > "under development / experimental" might be good. > > -Matthias > > > On 3/22/22 9:04 AM, Guozhang Wang wrote: >> Hi John, >> >> Originally I was leaning towards making IQv2 APIs more or less stable while >> being released for the first time, but after some second thoughts I'm now >> feeling it's okay to take it in a more evolving manner. So I'm preferring >> to keep it and be open for breaking changes in the future. >> >> >> Guozhang >> >> On Tue, Mar 22, 2022 at 8:27 AM John Roesler <vvcep...@apache.org> wrote: >> >>> Thanks Bruno, >>> >>> Yes, although IQv2 is not fully implemented (it doesn't >>> query global stores, and it doesn't support every query we >>> ultimately want), the queries that are implemnted do work as >>> expected. >>> >>> The main concern was that, right now, it's the job of the >>> Metered layer to translate queries and responses between >>> Java types and binary data. The suggestions that came in >>> after the KIP was approved were to consider moving to a >>> generic type-mapping API or to move to a lazy >>> de/serialization approach. I think either of those is a good >>> suggestion, but I haven't had time to really explore the >>> implementation to see how either would really pan out. >>> >>> You are correct, though, all these APIs are marked >>> "Evolving", so we can always break compatibility later if we >>> feel like we have a much better approach. >>> >>> Let's give the community a few days to chime in. If no one >>> votes to pull it out, I'll plan to just keep it in. If we do >>> remove it, then KIPs 805 and 806 would also be removed. >>> >>> Thanks, >>> -John >>> >>> On Tue, 2022-03-22 at 12:43 +0100, Bruno Cadonna wrote: >>>> Hi John, >>>> >>>> The already implemented query types work as expected, don't they? >>>> >>>> I do not know the specific concerns, but it seems that this is the >>>> situation that motivated you to mark the APIs as @Evolving. Keeping the >>>> IQv2 API in 3.2 does not contradict the accepted KIP, right? >>>> >>>> In case, we decided to remove the IQv2 API from 3.2, would that mean we >>>> also need to remove the existing query types specified in KIP-805 and >>>> KIP-806? >>>> >>>> BTW, I now realize that I mistakenly removed KIP-796 from the release >>>> plan for 3.2. Sorry for that! I will re-add it to the release plan. >>>> >>>> Best, >>>> Bruno >>>> >>>> On 22.03.22 02:50, John Roesler wrote: >>>>> Hello, all, >>>>> >>>>> During the PR reviews for this KIP, there were several late concerns >>> raised about the IQv2 APIs. I filed tickets under KAFKA-13479 and promised >>> to revisit them before the API was released. >>>>> >>>>> Unfortunately, I have not had time to circle back on those concerns. >>> Now that the 3.2 branch cut has happened, I can either remove the IQv2 API >>> from 3.2 and plan to address those concerns before 3.3, or we can go ahead >>> and release IQv2 as proposed and implemented. >>>>> >>>>> Note that the APIs are all marked @Evolving, so we can technically >>> break compatibility if we do find a better way to do something later. >>>>> >>>>> What is your preference? Release it, or wait? >>>>> >>>>> Thanks, >>>>> John >>>>> >>>>> On Mon, Nov 22, 2021, at 21:18, John Roesler wrote: >>>>>> Thanks for voting and for the discussion, all! >>>>>> >>>>>> The vote on KIP-796 passes with: >>>>>> 3 binding +1 (Bruno, Bill, and myself) >>>>>> 2 non-binding +1 (Patrick and Vasiliki) >>>>>> no vetoes >>>>>> >>>>>> The vote is now closed. If anyone has objections later on, >>>>>> please raise them, though! >>>>>> >>>>>> We will proceed with a series of pull requests to implement >>>>>> the framework, and we will also propose one or more small >>>>>> KIPs to propose specific queries. >>>>>> >>>>>> Thanks again, >>>>>> -John >>>>>> >>>>>> On Mon, 2021-11-22 at 12:11 -0500, Bill Bejeck wrote: >>>>>>> Thanks for the well-detailed KIP, John. >>>>>>> >>>>>>> It's a +1 (binding) from me. >>>>>>> >>>>>>> I want to point out one thing which I think is an oversight. The >>> "Example >>>>>>> Raw Query" scan includes a line using the >>> `kafkaStreams.serdesForStore` >>>>>>> method, but it's listed in the "Rejected Alternatives" section. >>>>>>> >>>>>>> Thanks, >>>>>>> Bill >>>>>>> >>>>>>> On Mon, Nov 22, 2021 at 9:22 AM Bruno Cadonna <cado...@apache.org> >>> wrote: >>>>>>> >>>>>>>> Thanks for the KIP, John! >>>>>>>> >>>>>>>> +1 (binding) >>>>>>>> >>>>>>>> Best, >>>>>>>> Bruno >>>>>>>> >>>>>>>> On 19.11.21 18:04, Vasiliki Papavasileiou wrote: >>>>>>>>> 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 >>>>>>>> <pstu...@confluent.io.invalid> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> +1 (non-binding), thanks John! >>>>>>>>>> -Patrick >>>>>>>>>> >>>>>>>>>> On Thu, Nov 18, 2021 at 12:27 AM John Roesler < >>> vvcep...@apache.org> >>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>> >>> >>
