[
https://issues.apache.org/jira/browse/KAFKA-5684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111779#comment-16111779
]
Guozhang Wang commented on KAFKA-5684:
--------------------------------------
1. regarding using `peek` to implement `print`: yes we have been trying to do
so in https://issues.apache.org/jira/browse/KAFKA-4772, but we did not yet
collapse {{KStreamPeek}} and {{KStreamPrint}} into the same class, mainly
because we were treating serdes unnecessarily specially.
2. as Paolo mentioned, since we know at construction time if the mapper is
provided or not, we can just wrap the serdes into the default mapper ONCE in
the {{init}} call with one condition check only; by doing this we can get rid
of the per-call condition check as {{instanceof}}.
> KStreamPrintProcessor as customized KStreamPeekProcessor
> --------------------------------------------------------
>
> Key: KAFKA-5684
> URL: https://issues.apache.org/jira/browse/KAFKA-5684
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Paolo Patierno
> Assignee: Paolo Patierno
> Priority: Minor
>
> Hi,
> the {{KStreamPrintProcessor}} is implemented from scratch (from the
> {{AbstractProcessor}}) and the same for the related supplier.
> It looks to me that it's just a special {{KStreamPeekProcessor}} with
> forwardDownStream to false and that allows the possibility to specify Serdes
> instances used if key/values are bytes.
> At same time used by a {{print()}} method it provides a fast way to print
> data flowing through the pipeline (while using just {{peek()}} you need to
> write the code).
> I think that it could be useful to refactoring the {{KStreamPrintProcessor}}
> as derived from the {{KStreamPeekProcessor}} customizing its behavior.
> Thanks,
> Paolo.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
