kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damian Guy <damian....@gmail.com>
Subject Re: Kafka Streams debugging with "no fluent" API choice
Date Tue, 01 Aug 2017 14:28:14 GMT
Yeah, right. Sorry i missed that. The JIRA doesn't need a KIP

On Tue, 1 Aug 2017 at 15:20 Paolo Patierno <ppatierno@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.guy@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 <ppatierno@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.guy@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 <ppatierno@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/>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message