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

Michael Noll commented on KAFKA-7653:
-------------------------------------

Thanks for raising this, [~mark.tranter]!  The issue makes sense to me.

Question for clarification:  The workaround today would be to explicitly 
specify the serdes you want (this way one can differentiate between key serdes 
vs. value serdes), but this would by definition negate the convenience in the 
Scala API where you normally do not need to do that (because of implicit 
serdes).  Right?

> 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
>            Priority: Minor
>
> 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