Andy, thanks for the KIP. I don't have any further comments.
My 2cents about Guozhang's questions: as I like consistent behavior, I think transfromValues() should behave the same way as filter() and mapValues(). -Matthias On 5/2/18 2:24 PM, Guozhang Wang wrote: > Hello Andy, > > Thanks for the KIP. The motivation and the general proposal looks good to > me. I think in KTable it is indeed valuable to add the functions that does > not change key, such as mapValues, transformValues, and filter. > > There are a few meta comments I have about the semantics of the newly added > functions: > > 1) For the resulted KTable, how should its "queryableStoreName()" be > returning? > > 2) More specifically, how do we decide if the resulted KTable is to be > materialized or not? E.g. if there is no store names provided then it is > likely that the resulted KTable is not materialized, or at least not > logically materialized and not be queryable. What if there is at least one > state store provided? Will any of them be provided as the materialized > store, or should we still add a Materialized parameter for this purpose? > > 3) For its internal implementations, how should the key/value serde, > sendOldValues flag etc be inherited from its parent processor node? > > > Guozhang > > > On Wed, May 2, 2018 at 12:43 PM, Andy Coates <a...@confluent.io> wrote: > >> Hi everyone, >> >> I would like to start a discussion for KIP 292. I would appreciate it if >> you could review and provide feedback. >> >> KIP: KIP-292: Add transformValues() method to KTable >> <https://cwiki.apache.org/confluence/display/KAFKA/KIP- >> 292%3A+Add+transformValues%28%29+method+to+KTable> >> Jira: KAFKA-6849 <https://issues.apache.org/jira/browse/KAFKA-6849> >> >> PR: #4959 <https://github.com/apache/kafka/pull/4959> >> >> >> >> Thanks, >> >> Andy >> > > >
signature.asc
Description: OpenPGP digital signature
