[
https://issues.apache.org/jira/browse/KAFKA-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695199#comment-16695199
]
Bruno Bieth edited comment on KAFKA-7654 at 11/21/18 8:35 PM:
--------------------------------------------------------------
[~mjsax] Thanks, I might end up writing a KIP if there is some support.
[~guozhang] Thanks for your thoughts as well! You make good points but I think
there is some confusion about circe. Circe serializers/deserializers (called
Encoder/Decoder) are built at compile-time rather than at runtime like
Avro/Jackson. Therefore you simply cannot define a generic circe-based Serde.
This is a _very_ good thing IMO.
I think we agree on 1) and 2) but about 3) what are the benefits of having a
global serde? As far as I can see it's about not doing
`builder.stream(jacksonSerde)`.
You could have for instance a `GenericSerde` (as opposed to a `Serde<T>`) and a
`builder#stream(GenericSerde): KStreamGeneric` which will carry your
GenericSerde throughout all the KStream operations. It's a few more classes but
nothing too dramatic.
was (Author: backuitist):
[~mjsax] Thanks, I might end up writing a KIP if there is some support.
[~guozhang] Thanks for your thoughts as well! You make good points but I think
there is some confusion about circe. Circe serializers/deserializers (called
Encoder/Decoder) are built at compile-time rather than at runtime like
Avro/Jackson. Therefore you simply cannot define a generic circe-based Serde.
This is a _very_ good thing IMO.
I think we agree on 1) and 2) but about 3) what are the benefits of having a
global serde? As far as I can see it's about not doing
`builder.stream(jacksonSerde)`.
You could have for instance a `GenericSerde` (as opposed to a `Serde<T>`) and a
`builder#stream(GenericSerde): KStreamGeneric` which will carry your
GenericSerde throughout all the KStream operations. It's a few more classes but
nothing too dramatic.
[~mjsax] If people stumble over the Java fluent interface then they should
probably not do distributed stream processing ;) I mean, come on, there are far
more complex things in the lib than that, it's like "no we cannot put the
safety on this machine gun because some people struggle with it" ;)
And we're not talking about crazy fluent interface (like
https://github.com/jOOQ/jOOQ/tree/master/jOOQ/src/main/java/org/jooq ).
So basically I agree in general about complexity and finding a threshold but in
that case I think it's fine. Of course I'm just a voice too :)
> Relax requirements on serializing-only methods.
> -----------------------------------------------
>
> Key: KAFKA-7654
> URL: https://issues.apache.org/jira/browse/KAFKA-7654
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Bruno Bieth
> Priority: Major
>
> Methods such as KStream#to shouldn't require a Produced as only the
> serializing part is ever used.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
