Hello John: * As for the type superclass, it is mainly for allowing super class serdes. More details can be found here: https://cwiki.apache.org/confluence/display/KAFKA/KIP-100+-+Relax+Type+constraints+in+Kafka+Streams+API
* I may have slight preference on reusing existing classes but I think most of my rationales are quite subjective. Personally I do not find `self documenting` worth a new class but I can be convinced if people have other motivations doing it :) Guozhang On Tue, May 15, 2018 at 11:19 AM, John Roesler <j...@confluent.io> wrote: > Thanks for the KIP, Guozhang. > > It looks good overall to me; I just have one question: > * Why do we bound the generics of KVMapper in KStream to be superclass-of-K > and superclass-of-V instead of exactly K and V, as in Topology? I might be > thinking about it wrong, but that seems backwards to me. If anything, > bounding to be a subclass-of-K or subclass-of-V would seem right to me. > > One extra thought: I agree that KVMapper<K,V,String /*topic name*/> is an > applicable type for extracting the topic name, but I wonder what the value > of reusing the KVMapper for this purpose is. Would defining a new class, > say TopicNameExtractor<K,V>, provide the same functionality while being a > bit more self-documenting? > > Thanks, > -John > > On Tue, May 15, 2018 at 12:32 AM, Guozhang Wang <wangg...@gmail.com> > wrote: > > > Hello folks, > > > > I'd like to start a discussion on adding dynamic routing functionality in > > Streams sink node. I.e. users do not need to specify the topic name at > > compilation time but can dynamically determine which topic to send to > based > > on each record's key value pairs. Please find a KIP here: > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > 303%3A+Add+Dynamic+Routing+in+Streams+Sink > > > > Any feedbacks are highly appreciated. > > > > Thanks! > > > > -- Guozhang > > > -- -- Guozhang
