[ 
https://issues.apache.org/jira/browse/KAFKA-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16698503#comment-16698503
 ] 

Matthias J. Sax commented on KAFKA-7653:
----------------------------------------

If an implicit can be written in a way such that it returns a new object each 
time, it might be fair to document this and make it a requirement.

For the second part: the compiler does not need to distinguish both cases IMHO. 
At runtime, we get two Serde-objects, one for the key, and one for the value, 
and we can call `configure()` correctly for each. Or do I miss something?

> Streams-Scala: Add type level differentiation for Key and Value serdes.
> -----------------------------------------------------------------------
>
>                 Key: KAFKA-7653
>                 URL: https://issues.apache.org/jira/browse/KAFKA-7653
>             Project: Kafka
>          Issue Type: Improvement
>          Components: streams
>            Reporter: Mark Tranter
>            Assignee: Mark Tranter
>            Priority: Minor
>              Labels: scala
>
> Implicit resolution/conversion of Serdes/Consumed etc is a big improvement 
> for the Scala Streams API. However in cases where a user needs to 
> differentiate between Key and Value serializer functionality (i.e. using the 
> Schema Registry), implicit resolution doesn't help and could cause issues. 
> e.g.
> {code:java}
> case class MouseClickEvent(pageId: Long, userId: String)
> builder
>   // Long serde taken from implicit scope configured with
>   // `isKey` = true
>   .stream[Long, MouseClickEvent]("mouse-clicks")
>   .selectKey((_,v) => v.userId)
>   .groupByKey
>   .aggregate(() => 0L, (_: String, mce: MouseClickEvent, count: Long) => 
> count + 1)
>   .toStream
>   // Same Long serde taken from implicit scope configured with
>   // `isKey` = true, even thought the `Long` value in this case
>   // will be the Value
>   .to("mouse-clicks-by-user")
> {code}
> It would be ideal if Key and Value Serde/SerdeWrapper types/type classes 
> could be introduced to overcome this limitation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to