Jan, I understand what you are saying. However, having a RecordContext is super useful for operations that are applied to input topic. Many users requested this feature -- it's much more convenient that falling back to transform() to implement a a filter() for example that want to access some meta data.
Because we cannot distinguish different "origins" of a KStream/KTable, I am not sure if there would be a better way to do this. The only "workaround" I see, is to have two KStream/KTable interfaces each and we would use the first one for KStream/KTable with "proper" RecordContext. But this does not seem to be a good solution either. Note, a KTable can also be read directly from a topic, I agree that using RecordContext on a KTable that is the result of an aggregation is questionable. But I don't see a reason to down vote the KIP for this reason. WDYT about this? -Matthias On 11/1/17 10:19 PM, Jan Filipiak wrote: > -1 non binding > > I don't get the motivation. > In 80% of my DSL processors there is no such thing as a reasonable > RecordContext. > After a join the record I am processing belongs to at least 2 topics. > After a Group by the record I am processing was created from multiple > offsets. > > The API Design doesn't look appealing > > Best Jan > > > > On 01.11.2017 22:02, Jeyhun Karimov wrote: >> Dear community, >> >> It seems the discussion for KIP-159 [1] converged finally. I would >> like to >> initiate voting for the particular KIP. >> >> >> >> [1] >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-159%3A+Introducing+Rich+functions+to+Streams >> >> >> Cheers, >> Jeyhun >> >
signature.asc
Description: OpenPGP digital signature
