Apologies for the delay.
I have made the changes in the KIP, i'll be starting the voting process
shortly.
Best regards,
Aishwarya Kumar
On Mon, Oct 7, 2019 at 6:06 PM Matthias J. Sax
wrote:
> Aishwarya,
>
> Why is bullet point (2) formatted as "strike through"? If you intend to
> replace it
Any update on this KIP?
On 10/7/19 3:06 PM, Matthias J. Sax wrote:
> Aishwarya,
>
> Why is bullet point (2) formatted as "strike through"? If you intend to
> replace it with bullet point (3), just remove it completely. The KIP
> should reflect the actual proposal. Maybe move it to "Rejected
>
Aishwarya,
Why is bullet point (2) formatted as "strike through"? If you intend to
replace it with bullet point (3), just remove it completely. The KIP
should reflect the actual proposal. Maybe move it to "Rejected
Alternative" section?
For (3c), it should also say, if `Materialize` specifies a
Thank you all for the feedback, I will keep this thread open for discussion
for a couple of more days and then start with the voting process.
Best regards,
Aishwarya
On Fri, Sep 27, 2019, 12:37 PM John Roesler wrote:
> Looks good to me! I have no further comments.
>
> Thanks again for the KIP,
Looks good to me! I have no further comments.
Thanks again for the KIP, Aishwarya!
-John
On Fri, Sep 27, 2019 at 10:11 AM aishwarya kumar wrote:
>
> Hello John,
>
> Thank you for pointing this out to me, to maintain consistency across API's
> it does make sense to allow users to define custom
Hello John,
Thank you for pointing this out to me, to maintain consistency across API's
it does make sense to allow users to define custom names for
their processors.
I've made the change in the KIP:
Hey Aishwarya,
Thanks for the KIP! It looks good to me, although in a post-KIP-307
world, we also need a "Named" parameter (to give the processor node a
name, as opposed to the store itself).
This would result in a total of four overloads:
1. no args
2. Named
3. Materialized
4. Materialized,
Thank you for the suggestion Matthais, i've made the necessary changes in
the KIP.
Keeping this thread open for further input.
KIP link:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-523%3A+Add+KStream%23toTable+to+the+Streams+DSL
Best,
Aishwarya
On Thu, Sep 19, 2019 at 10:50 AM
Thanks Matthias,
That does make sense, let me update the KIP to reflect the Materialization
scenario.
Best,
Aishwarya
On Tue, Sep 17, 2019, 2:49 PM Matthias J. Sax wrote:
> Aishwarya,
>
> thanks for the KIP. Overall, I think it makes sense to allow converting
> a KStream into a KTable.
>
>
Aishwarya,
thanks for the KIP. Overall, I think it makes sense to allow converting
a KStream into a KTable.
From the KIP:
> materializing these KTables should only be allowed if the overloaded function
> with Materialized is used (and if optimization is turned on it may still be
> only
Hi All,
Keeping this thread alive!!
The aim is to add two methods Kstream.toTable() &
Kstream.toTable(Materialized), so users can choose to convert their
event stream into a changelog stream at any stage.
wiki link :
Hello,
Starting this thread to discuss KIP-532:
wiki link :
https://cwiki.apache.org/confluence/display/KAFKA/KIP-523:+Add+KStream%23toTable+to+the+Streams+DSL
jira ticket : https://issues.apache.org/jira/browse/KAFKA-7658
There has been some discussion around the use-case of this KIP in the
12 matches
Mail list logo
