Hi Paolo, The change would require a KIP as it is a public API change. I don't see any harm in making the change, but I also don't think it is that difficult to use peek to achieve the same thing.
Thanks, Damian On Tue, 1 Aug 2017 at 13:52 Paolo Patierno <ppatie...@live.com> wrote: > 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/> > > >
