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 > -- -- Guozhang
