[ https://issues.apache.org/jira/browse/KAFKA-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692440#comment-16692440 ]
Mark Tranter commented on KAFKA-7653: ------------------------------------- Thanks [~miguno] Yes that is one workaround. And as you say, negates the use of implicit serdes. Another option might be to wrap the types to be serialized {code:java} case class StringKey(k: String) case class Value(v: String){code} Then use these types within the Streams Builder and write basic wrapper serializers for these wrapper types. Again not ideal. I'm more than happy to help out with a fix for this if we can decide on an appropriate abstraction to use. I cant see a nice way of doing it currently that wouldn't cause breaking changes to existing users. Thanks for your reply! > 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)