Thanks Guozhang. > Does `ValueProcessorContext` have to be a public API? It seems to me that this can be completely abstracted away from user interfaces as an internal class
Totally agree. No intention to add these as public APIs. Will update the KIP to reflect this. > in the past the rationale for enforcing it at the interface layer rather than do runtime checks is that it is more efficient. > I'm not sure how much overhead it may incur to check if the key did not change: if it is just a reference equality check maybe it's okay. What's your take on this? Agree, reference equality should cover this validation and the overhead impact should not be meaningful. Will update the KIP to reflect this as well. On Tue, 8 Feb 2022 at 19:05, Guozhang Wang <wangg...@gmail.com> wrote: > Hello Jorge, > > Thanks for bringing this KIP! I think this is a nice idea to consider using > a single overloaded function name for #process, just a couple quick > questions after reading the proposal: > > 1) Does `ValueProcessorContext` have to be a public API? It seems to me > that this can be completely abstracted away from user interfaces as an > internal class, and we call the `setKey` before calling user-instantiated > `process` function, and then in its overridden `forward` it can just check > if the key changes or not. > 2) Related to 1) above, in the past the rationale for enforcing it at the > interface layer rather than do runtime checks is that it is more efficient. > I'm not sure how much overhead it may incur to check if the key did not > change: if it is just a reference equality check maybe it's okay. What's > your take on this? > > > Guozhang > > On Tue, Feb 8, 2022 at 5:17 AM Jorge Esteban Quilcate Otoya < > quilcate.jo...@gmail.com> wrote: > > > Hi Dev team, > > > > I'd like to start a new discussion thread on Kafka Streams KIP-820: > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-820%3A+Extend+KStream+process+with+new+Processor+API > > > > This KIP is aimed to extend the current `KStream#process` API to return > > output values that could be chained across the topology, as well as > > introducing a new `KStream#processValues` to use processor while > validating > > keys haven't change and repartition is not required. > > > > Looking forward to your feedback. > > > > Regards, > > Jorge. > > > > > -- > -- Guozhang >
