Hi,
Given the lack of any further comments or new votes, I'm assuming everyone
who already voted is still in agreement and I will close the vote.
The vote passed with 3 binding +1 votes (Guozhang, Sriram, Jason)
and 2 non-binding +1 votes (Bill, Eno)
Thank you,
Xavier
On Fri, May 12, 2017 at 9:
Thanks for the note Michael, I think it makes sense.
And thinking about it more, I also agree that even for single-key fetch on
ReadOnlyWindow/SessionStore it's better to return the Iterator,
V> even when the windowed key's key field would always be the same, as it
is more consistent with the adde
Thanks Michal, you are correct. I can see your point now, and I can get
behind returning Windowed as well for windowed stores.
It might make sense to revisit the single key iterator in the future and do
the same for consistency, but I'd rather not break backwards compatibility
unless we have a goo
Also, wrt
In the case of the window store, the "key" of the single-key iterator is
the actual timestamp of the underlying entry, not just range of the
window,
so if we were to wrap the result key a window we wouldn't be getting back
the equivalent of the single key iterator.
I believe the tim
Well, another concern, apart from potential confusion, is that you won't be
able to peek the actual next key, just the timestamp. So the tradeoff is
between having consistency in return types versus consistency in having the
ability to know the next key without moving the iterator. To me the lat
+1
Thanks
Eno
> On 10 May 2017, at 20:25, Michal Borowiecki
> wrote:
>
> Apologies, I missed the discussion (or lack thereof) about the return type of:
>
> WindowStoreIterator> fetch(K from, K to, long timeFrom, long
> timeTo)
>
>
> WindowStoreIterator (as the KIP mentions) is a subclass o
+1
On Wed, May 10, 2017 at 1:45 PM, Xavier Léauté wrote:
> Thank you for the feedback Michal.
>
> While I agree the return may be a little bit more confusing to reason
> about, the reason for doing so was to keep the range query interfaces
> consistent with their single-key counterparts.
>
> In
Thank you for the feedback Michal.
While I agree the return may be a little bit more confusing to reason
about, the reason for doing so was to keep the range query interfaces
consistent with their single-key counterparts.
In the case of the window store, the "key" of the single-key iterator is
th
Apologies, I missed the discussion (or lack thereof) about the return
type of:
WindowStoreIterator> fetch(K from, K to, long timeFrom,
long timeTo)
WindowStoreIterator (as the KIP mentions) is a subclass of
KeyValueIterator
KeyValueIterator has the following method:
/** * Peek at the nex
+1
On Wed, May 10, 2017 at 11:42 AM, Bill Bejeck wrote:
> +1
>
> Thanks,
> Bill
>
> On Wed, May 10, 2017 at 2:38 PM, Guozhang Wang wrote:
>
> > +1. Thank you!
> >
> > On Wed, May 10, 2017 at 11:30 AM, Xavier Léauté
> > wrote:
> >
> > > Hi everyone,
> > >
> > > Since there aren't any objections
+1
Thanks,
Bill
On Wed, May 10, 2017 at 2:38 PM, Guozhang Wang wrote:
> +1. Thank you!
>
> On Wed, May 10, 2017 at 11:30 AM, Xavier Léauté
> wrote:
>
> > Hi everyone,
> >
> > Since there aren't any objections to this addition, I would like to start
> > the voting on KIP-155 so we can hopefully
+1. Thank you!
On Wed, May 10, 2017 at 11:30 AM, Xavier Léauté wrote:
> Hi everyone,
>
> Since there aren't any objections to this addition, I would like to start
> the voting on KIP-155 so we can hopefully get this into 0.11.
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP+
> 155+-+Ad
Hi everyone,
Since there aren't any objections to this addition, I would like to start
the voting on KIP-155 so we can hopefully get this into 0.11.
https://cwiki.apache.org/confluence/display/KAFKA/KIP+155+-+Add+range+scan+for+windowed+state+stores
Voting will stay active for at least 72 hours.
13 matches
Mail list logo
