[
https://issues.apache.org/jira/browse/KAFKA-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Schlansker updated KAFKA-4726:
-------------------------------------
Description:
{{ValueMapper}} should have read-only access to the key for the value it is
mapping. Sometimes the value transformation will depend on the key.
It is possible to do this with a full blown {{KeyValueMapper}} but that loses
the promise that you won't change the key -- so you might introduce a re-keying
phase that is totally unnecessary. It also requires you to return an identity
KeyValue object which costs something to construct (unless we are lucky and the
optimizer elides it).
[ If mapValues() is guaranteed to be no less efficient than map() the issue may
be moot, but I presume there are some optimizations that are valid with the
former but not latter. ]
was:
{{ValueMapper}} should have read-only access to the key for the value it is
mapping. Sometimes the value transformation will depend on the key.
It is possible to do this with a full blown {{KeyValueMapper}} but that loses
the promise that you won't change the key -- so you might introduce a re-keying
phase that is totally unnecessary.
[ If mapValues() is guaranteed to be no less efficient than map() the issue may
be moot, but I presume there are some optimizations that are valid with the
former but not latter. ]
> ValueMapper should have (read) access to key
> --------------------------------------------
>
> Key: KAFKA-4726
> URL: https://issues.apache.org/jira/browse/KAFKA-4726
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Affects Versions: 0.10.1.1
> Reporter: Steven Schlansker
>
> {{ValueMapper}} should have read-only access to the key for the value it is
> mapping. Sometimes the value transformation will depend on the key.
> It is possible to do this with a full blown {{KeyValueMapper}} but that loses
> the promise that you won't change the key -- so you might introduce a
> re-keying phase that is totally unnecessary. It also requires you to return
> an identity KeyValue object which costs something to construct (unless we are
> lucky and the optimizer elides it).
> [ If mapValues() is guaranteed to be no less efficient than map() the issue
> may be moot, but I presume there are some optimizations that are valid with
> the former but not latter. ]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
