Hi.
I do understand that it might come in Handy.
From my POV in any relational algebra this is only a projection.
Currently we hide these "fields" that come with the input record.
It should be 100% sufficient to offer a KTable + KStream that is directly
feed from a topic with 1 additional overload for the #map() methods to
cover every usecase while keeping the API in a way better state.
best Jan
On 06.11.2017 17:52, Matthias J. Sax wrote:
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
