Personally, I like the idea of builders for the producer/consumer themselves,
but I'm less enthusiastic about one for ProducerRecord. Mostly because I think
the following is overly verbose/reads poorly:
producer.send(ProducerRecord.builder()
.topic("mytopic")
.key("Key")
.value("the-val")
.headers(myHeaderIterable)
.build());
as compared to:
producer.send(new ProducerRecord("mytopic", "Key", "the-val",
myHeaderIterable));
I think constructor overloads are fine for small data classes like this. The
producer/consumer clietns themselves have a lot of options represented by
various configuration keys, and a builder pattern makes these easily
discoverable in code.
-Tommy
On Wed, 2018-07-04 at 15:42 +0200, Matthias Wessendorf wrote:
Hi,
I was filing KAFKA-7059 ([1]) and sent a PR adding a new ctor:
--
public ProducerRecord(String topic, K key, V value, Iterable<Header>
headers)
---
One reasonable comment on the PR was instead of doing constructor
overloading, why not working on a builder for the ProducerRecord class.
I think this is generally a nice idea I was wondering if there is much
interest in ?
Sample:
---
final ProducerRecord<String, String> myRecord = ProducerRecord.builder() //
or an exposed builder
.topic("mytopic")
.key("Key")
.value("the-val")
.headers(myHeaderIterable)
.build();
---
While at it - instead of just offering a builder for the "ProducerRecord"
class, why not adding a builder for the "KafkaProducer" and "KafkaConsumer"
clazzes.
---
final KafkaProducer<String, String> myProducer = KafkaProducer.builder() //
or an exposed builder clazz
.config(myProducerConfig)
.keySerializer(myStringSerializer)
.valueSerializer(myStringSerializer)
.build();
---
to even make the above more nice, I think the "ProducerConfig" (analog the
ConsumerConfig) configuration options could be also made accesible w/ this
fluent API - instead of properties/map, which is what now dominates the
creation of the Consumers/Producers.
Any thoughts? If there is interest, I am happy to start a KIP w/ a first
draft of the suggested API!
Cheers,
Matthias
[1] https://issues.apache.org/jira/browse/KAFKA-7059
________________________________
This email and any attachments may contain confidential and privileged material
for the sole use of the intended recipient. Any review, copying, or
distribution of this email (or any attachments) by others is prohibited. If you
are not the intended recipient, please contact the sender immediately and
permanently delete this email and any attachments. No employee or agent of TiVo
Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by
email. Binding agreements with TiVo Inc. may only be made by a signed written
agreement.