Thanks Damian,
I knew about that but you have to write the code for printing by yourself. Of course you can do that even with the print() without using the default keyvalue mapper but passing a custom one. At same time if you want to print you should use a Serdes for key and value if they are bytes and it's something which happens for free with print() passing Serdes instances. Another point is ... as both foreach() and peek() methods relies on the KStreamPeek node, it could be the same for the print() method which uses a KStreamPrint that is a special KStreamPeek with forwardDownStream = false and providing the usage of Serdes. For this I have opened the following JIRA : https://issues.apache.org/jira/browse/KAFKA-5684 What do you think ? Thanks Paolo Patierno Senior Software Engineer (IoT) @ Red Hat Microsoft MVP on Windows Embedded & IoT Microsoft Azure Advisor Twitter : @ppatierno<http://twitter.com/ppatierno> Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno> Blog : DevExperience<http://paolopatierno.wordpress.com/> ________________________________ From: Damian Guy <damian....@gmail.com> Sent: Tuesday, August 1, 2017 12:11 PM To: dev@kafka.apache.org Subject: Re: Kafka Streams debugging with "no fluent" API choice I don't know specifically why this is removed, however if you want to get the same functionality you can use peek, i.e: stream.map(...).peek(...).filter(..) You can log the key values out in the peek call. On Tue, 1 Aug 2017 at 11:48 Paolo Patierno <ppatie...@live.com> wrote: > Hi guys, > > > I was thinking about Kafka Streams debug features and why the print() > method overloads didn't return a KStream, in order to have a fluent DSL > construction even during debugging, but just void. > > Then I came across this PR : > > > https://github.com/apache/kafka/pull/1187 > > > May I ask why the form : > > > stream1 = source.map(...).filter(...); > stream1.print(); // this is for debugging, deleted before moving to > productiong > > stream2 = stream1.transform(...); > stream2.print(); // this is for debugging, deleted before moving to > productiong > > was considered better then the fluent one : > > > source.map(...).filter(...) > .print() // this is for debugging, deleted before moving to > productiong > .transform(...) > .print(); // this is for debugging, deleted before moving to > productiong > > > In this first case the user has to break the topology for printing and > after that, when the code works fine, he has to rewrite the code for > avoiding these broken processors having a fluent construction. > > In the second solution, the user has just to remove the print() calls > without touching the other parts of the code. > > I really liked the first solution (it was something I was going to propose > before coming across the PR :-)). > > > Why this preference on the first one ? > > > Thanks > > > > Paolo Patierno > Senior Software Engineer (IoT) @ Red Hat > Microsoft MVP on Windows Embedded & IoT > Microsoft Azure Advisor > > Twitter : @ppatierno<http://twitter.com/ppatierno> > Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno> > Blog : DevExperience<http://paolopatierno.wordpress.com/> >
