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
