Thanks for the clarification, it looks good to me now.
On Wed, Nov 17, 2021 at 9:21 PM John Roesler wrote:
> Ah, sorry, Guozhang,
>
> It seem I was a bit too eager with starting the vote thread.
>
> 13: I think that makes perfect sense. I've updated the KIP.
>
> 14: Oof, I can't believe I
Ah, sorry, Guozhang,
It seem I was a bit too eager with starting the vote thread.
13: I think that makes perfect sense. I've updated the KIP.
14: Oof, I can't believe I overlooked those newer
exceptions. Some of them will become exceptions in IQv2,
whereas others will beceome individual
Thanks John.
I made another pass on the KIP and overall it already looks pretty good. I
just have a couple more minor comments:
13: What do you think about just removing the following function in
QueryResult
// returns a failed query result because caller requested a "latest"
bound, but the
Thanks for the reply, Guozhang!
I have updated the KIP to tie up the remaining points that
we have discussed. I really appreciate your time in refining
the proposal. I included a quick summary of the final state
of our discussion points below.
Since it seems like this discussion thread is pretty
Thanks for the reply, Sagar,
Thanks for bringing up the point about documentation, I do
think it would be a great idea for us to add a section to
the IQ doc page that's basically a "store extension guide"
that gives an overview of how to implement custom queries
and custom stores. That would help
Thanks John for answering the 2 questions. Pt #1 makes sense to me now.
Regarding Pt #2, first of all thanks for bringing up KIP-614 :D I did learn
about the interfaces the hard way and probably due to that, the PR really
stretched a lot. Having said that, the point that you mentioned about any
Thanks John! Some more thoughts inlined below.
On Mon, Nov 15, 2021 at 10:07 PM John Roesler wrote:
> Thanks for the review, Guozhang!
>
> 1. This is a great point. I fell into the age-old trap of
> only considering the simplest store type and forgot about
> this extra wrinkle of the "key
Thanks for the review, Guozhang!
1. This is a great point. I fell into the age-old trap of
only considering the simplest store type and forgot about
this extra wrinkle of the "key schema" that we use in
Windowed and Session stores.
Depending on how we want to forge forward with our provided
Hello John,
Great, great, great writeup! :) And thank you for bringing this up finally.
I have made a pass on the KIP as well as the POC PR of it, here are some
initial thoughts:
First are some meta ones:
1. Today the serdes do not only happen at the metered-store layer,
unfortunately. For
Hi Patrick and Sagar,
Thanks for the feedback! I'll just break out the questions
and address them one at a time.
Patrick 1.
The default bound that I'm proposing is only to let active
tasks answer queries (which is also the default with IQ
today). Therefore, calling getPositionBound() would
Hi John,
Thanks for the great writeup! Couple of things I wanted to bring up(may or
mayn't be relevant):
1) The sample implementation that you have presented for KeyQuery is very
helpful. One thing which may be added to it is how it connects to the
KeyValue.get(key) method. That's something that
Hi John,
Thanks for submitting the KIP! One question I have is, assuming one
instantiates InteractiveQueryRequest via withQuery, and then later calls
getPositionBound, what will the result be? Also I noticed the Position
returning method is in InteractiveQueryRequest and InteractiveQueryResult
is
Thanks for taking a look, Sophie!
Ah, that was a revision error. I had initially been planning
an Optional> with Optional.empty() meaning to
fetch all partitions, but then decided it was needlessly
complex and changed it to the current proposal with two
methods:
boolean isAllPartitions();
Set
Thanks John, I've been looking forward to this for a while now. It
was pretty horrifying to learn
how present-day IQ works (or rather, doesn't work) with custom state
stores :/
One minor cosmetic point, In the InteractiveQueryRequest class, the #
getPartitions
method has a return type of Set,
Hello again, all,
Just bumping this discussion on a new, more flexible
Interactive Query API in Kafka Streams.
If there are no concerns, I'll go ahead and call a vote on
Monday.
Thanks!
-John
On Tue, 2021-11-09 at 17:37 -0600, John Roesler wrote:
> Hello all,
>
> I'd like to start the
Hello all,
I'd like to start the discussion 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
I look forward to your feedback!
Thank you,
-John
16 matches
Mail list logo
