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
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,
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.
Guoz
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
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 decid
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
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 req
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
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
wrote:
+1 (non-binding), thanks
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
+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
Obviously, I will be voting +1 (binding)
Thanks,
-John
On Wed, 2021-11-17 at 17:27 -0600, 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/co
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,
-Jo
13 matches
Mail list logo