Thanks Matthias for the reply
I think i like the idea of the ability to use Record context in the default
partitioner itself. I will join the discussion for KIP 478 to understand the
context.
On 2020/09/11 21:31:46, "Matthias J. Sax" wrote:
> With regard to KIP-478, there is the idea to introd
Thanks for taking time to reply.
I thought about the confusion with overloads. creating another Partitioner
seemed liked a good idea to start with, soon i realized the partitioner is
interface written in a way which does not support anything other than
key/value. It seems to me the idea of using
With regard to KIP-478, there is the idea to introduce a `RecordContext`
class.
Thus, we could just change the `StreamPartitioner` to take this new
class as parameter to `partition()`? This might actually kill two birds
with one stone, because I could imagine use cases in which users want to
parti
Hey Balan, thanks for the KIP!
The motivation here makes sense to me, but I have a few questions about the
proposed API
I guess the main thing to point out is that if we just add new addSink()
overloads to Topology,
then only the lower level Processor API will benefit and users of the DSL
won't b
Forgot to add the link
https://cwiki.apache.org/confluence/display/KAFKA/KIP-669%3A+Preserve+Source+Partition+in+Kafka+Streams+from+context
On 2020/09/10 13:40:02, satyanarayan komandur wrote:
> Hi,
>
> I have submitted a new KIP for preserving processor record context partition
> from sou
Hi,
I have submitted a new KIP for preserving processor record context partition
from source. I am looking for suggestions/comments.
In most use cases where source message is getting transformed and sent to a
target topic, where
1. number of partitions on source and sink topic are same
2. ther
