Hey everyone!
Thank you for participating.
The KIP-813 vote has passed with:
binding +1s (John, Matthias, Bill)
non-binding +1s (Daan, Federico)
Cheers,
D.
From: John Roesler
Date: Friday, 1 April 2022 at 15:54
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-813 Shared State Stores
data. Either way, I would not add that into this KIP
>>> since it is a specific use-case pattern.
>>>
>>> Unless there is anything more to add or change, I would propose moving to a
>>> vote?
>>>
>>> Cheers!
>>> D.
>>>
>>
. But we get that by
implementing these readonly statestores as regular ones right?
Cheers,
D.
From: John Roesler
Date: Friday, 1 April 2022 at 04:01
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-813 Shared State Stores
Hi Daan,
Thanks for the KIP!
I just got caught up on the discussion
gt;> the data. Either way, I would not add that into this KIP since it is a
>> specific use-case pattern.
>>
>> Unless there is anything more to add or change, I would propose moving to a
>> vote?
>>
>> Cheers!
>> D.
>>
>> From: Matthia
e.org
Subject: Re: [DISCUSS] KIP-813 Shared State Stores
Thanks for updating the KIP!
I am wondering if we would need two overloads of `addReadOnlyStateStore`
one w/ and one w/o `TimestampExtractor` argument to effectively make it
an "optional" parameter?
Also wondering if we need to pa
is a specific
use-case pattern.
Unless there is anything more to add or change, I would propose moving to a
vote?
Cheers!
D.
From: Matthias J. Sax
Date: Friday, 18 February 2022 at 03:29
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-813 Shared State Stores
Thanks for updating the KIP
th the changes to the motivation etc. Only thing to
figure
out is that restoring behavior to be sure processors of the readonly
statestore aren't working with stale data.
D.
-Original Message-
From: Matthias J. Sax
Sent: 19 January 2022 21:31
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KI
e, no?
>
> As always, thanks for your insights.
>
> Cheers,
> D.
>
>
> From: Matthias J. Sax
> Date: Wednesday, 16 February 2022 at 02:09
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-813 Shared State Stores
> Thanks for updating the KIP.
>
> C
ate: Wednesday, 16 February 2022 at 02:09
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-813 Shared State Stores
Thanks for updating the KIP.
Could you add more details about the signature of
`addReadOnlyStateStore()` -- What parameters does it take? Are there any
overloads taking different paramete
to be sure processors of the readonly
statestore aren't working with stale data.
D.
-Original Message-
From: Matthias J. Sax
Sent: 19 January 2022 21:31
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-813 Shared State Stores
Daan,
thanks for the KIP. I personally find the motiv
g a read-only store v.s. adding a global
> store?
>
> I think because of the first answer the behavior differs from global
> stores.
>
> Makes sense?
>
> Cheers,
>
> D.
>
> From: Matthias J. Sax
> Date: Thursday, 20 January 2022 at 21:12
> To: dev@kafka.ap
; disabled, it means there is no initial restoration going on. As you wrote,
>> the DSL is already doing this, so I'm pretty sure I'm missing something,
>> just unable to find what exactly.
>>
>> I will rewrite the parts in the KIP to make processor-based the prefer
ng with stale data.
D.
-----Original Message-----
From: Matthias J. Sax
Sent: 19 January 2022 21:31
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-813 Shared State Stores
Daan,
thanks for the KIP. I personally find the motivation section a little bit
confusing. If I understand the KIP correctly
hat exactly.
>
> I will rewrite the parts in the KIP to make processor-based the preferred
> choice, along with the changes to the motivation etc. Only thing to figure
> out is that restoring behavior to be sure processors of the readonly
> statestore aren't working with stale data.
&g
rocessors of the readonly statestore
aren't working with stale data.
D.
-Original Message-
From: Matthias J. Sax
Sent: 19 January 2022 21:31
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-813 Shared State Stores
Daan,
thanks for the KIP. I personally find the motivation s
Daan,
thanks for the KIP. I personally find the motivation section a little
bit confusing. If I understand the KIP correctly, you want to read a
topic into a state store (ie, materialize it). This is already possible
today.
Of course, today a "second" changelog topic would be created. It see
16 matches
Mail list logo
