Ismael's comment is quite reasonable.

And I actually like the idea about `withForcedPartition` -- it helps
newcomers to understand the API better. Even if I don't agree with some
of you reasoning:

> I was always told that the key is solely the determining factor

Bad teacher?

> I find it incredibly unintuitive and dangerous to provide the users the 
> ability to force a partition

Disagree completely. This is a very useful feature for advanced use
cases. Btw: users can also specify a custom partitioner -- and this
custom partitioner could also do any computation to determine the
partitions (it also has access to key and value -- thus, it could also
use the value to compute the partition).

But I like `withForcedPartition` because it indicates that the
partitioner (default or custom) is not going to be used for this case.


Btw: if we plan to make `public ProducerRecord(String topic, Integer
partition, Long timestamp, K key, V value)` protected as some point, we
should deprecate it, too.


I also like the compromise you suggest

>> public ProducerRecordBuilder(String topic, K key, V value)
>> 
>> coming with withPartition and withTimestamp?  


The only thing, I still don't like is that we use a builder and are thus
forced to call .build() -- boilerplate.

Maybe we would just change ProducerRecord itself? Like:

new ProducerRecord(topic, key,
value).withTimestamp(ts).withForcedPartition(p);

WDYT?


-Matthias

On 4/20/17 4:57 PM, Stephane Maarek wrote:
> Matthias: I was definitely on board with you at first, but Ismael made the 
> comment that for:
> 
> public ProducerRecord(String topic, K key, V value, Integer partition)
> public ProducerRecord(String topic, K key, V value, Long timestamp)
> 
> Integer and Long are way too close in terms of meaning, and could provide a 
> strong misuse of the timestamp / partition field. 
> Therefore I started with a builder pattern for explicit argument declaration. 
> Seems like a lot of boilerplate, but it makes things quite easy to understand.
> 
> I like your point about the necessity of the key, and that users should set 
> it to null explicitely.
> 
> Damian: I like your idea of public ProducerRecordBuilder(String topic, V 
> value)
> Finally, I also chose the withForcedPartition because in my learning of 
> Kafka, I was always told that the key is solely the determining factor to 
> know how a messages makes it to a partition. I find it incredibly unintuitive 
> and dangerous to provide the users the ability to force a partition. If 
> anything they should be providing their own key -> partition mapping, but I’m 
> really against letting users force a partition within the producerRecord. 
> What do you think?
> 
> 
> What do you both think of the more opiniated:
> 
> public ProducerRecordBuilder(String topic, K key, V value)
> 
> coming with withPartition and withTimestamp?  
> 
> 
> 
> On 21/4/17, 2:24 am, "Matthias J. Sax" <matth...@confluent.io> wrote:
> 
>     Thanks for the KIP!
>     
>     While I agree, that the current API is not perfect, I am not sure if a
>     builder pattern does make sense here, because it's not too many 
> parameters.
>     
>     IMHO, builder pattern makes sense if there are many optional parameters.
>     For a ProducerRecord, I think there are only 2 optional parameters:
>     partition and timestamp.
>     
>     I don't think key should be optional, because uses should be "forced" to
>     think about the key argument as it effects the partitioning. Thus,
>     providing an explicit `null` if there is no key seems reasonable to me.
>     
>     Overall I think that providing 3 overloads would be sufficient:
>     
>     > public ProducerRecord(String topic, K key, V value, Integer partition)
>     > public ProducerRecord(String topic, K key, V value, Long timestamp)
>     > public ProducerRecord(String topic, K key, V value, Integer partition, 
> Long timestamp)
>     
>     
>     Just my 2 cents.
>     
>     -Matthias
>     
>     
>     On 4/20/17 4:20 AM, Damian Guy wrote:
>     > Hi Stephane,
>     > 
>     > Thanks for the KIP.  Overall it looks ok, though i think the builder 
> should
>     > enforce the required parameters by supplying them via the constructor, 
> i.e,
>     > 
>     > public ProducerRecordBuilder(String topic, V value)
>     > 
>     > You can then remove the withValue and withTopic methods
>     > 
>     > I also think withForcedPartition should just be withPartition
>     > 
>     > Thanks,
>     > Damian
>     > 
>     > On Wed, 19 Apr 2017 at 23:34 Stephane Maarek 
> <steph...@simplemachines.com.au>
>     > wrote:
>     > 
>     >> Hi all,
>     >>
>     >> My first KIP, let me know your thoughts!
>     >>
>     >> 
> https://cwiki.apache.org/confluence/display/KAFKA/KIP+141+-+ProducerRecordBuilder+Interface
>     >>
>     >>
>     >> Cheers,
>     >> Stephane
>     >>
>     > 
>     
>     
> 
> 

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to