Yeah, right. Sorry i missed that. The JIRA doesn't need a KIP On Tue, 1 Aug 2017 at 15:20 Paolo Patierno <ppatie...@live.com> wrote:
> Hi Damian, > > > changing the print() method for sure needs a KIP but I guess there is some > reason we don't know why they decided to not have a fluent API for that. > > Regarding my JIRA I don't think a KIP is required, it's just internal > stuff ... no ? > > > 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 2:11 PM > To: dev@kafka.apache.org > Subject: Re: Kafka Streams debugging with "no fluent" API choice > > 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/> > > > > > >
