[
https://issues.apache.org/jira/browse/KAFKA-10472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110009#comment-18110009
]
Matthias J. Sax commented on KAFKA-10472:
-----------------------------------------
We didn't have any issue with the API, so I am not sure if we would really gain
much doing it TBH? Atm, I don't see a huge advantage it changing the API.
\cc [~bbejeck] [~lucasbru] [~alisa23] WDYT?
> Consider migrating Topology methods to the Builder pattern
> ----------------------------------------------------------
>
> Key: KAFKA-10472
> URL: https://issues.apache.org/jira/browse/KAFKA-10472
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: John Roesler
> Assignee: Hrishi Baskaran
> Priority: Minor
> Labels: need-kip
>
> During code review for KIP-478, I got this feedback from [~bbejeck] .
> In Topology, we have methods like this:
> {code:java}
> public synchronized <KIn, VIn> Topology addGlobalStore(
> final StoreBuilder<?> storeBuilder,
> final String sourceName,
> final TimestampExtractor timestampExtractor,
> final Deserializer<KIn> keyDeserializer,
> final Deserializer<VIn> valueDeserializer,
> final String topic,
> final String processorName,
> final ProcessorSupplier<KIn, VIn, Void, Void> stateUpdateSupplier){code}
> It would probably be better UX to preset a builder interface like:
> {code:java}
> public synchronized <KIn, VIn> Topology addGlobalStore(
> AddGlobalStoreParameters.fromStoreBuilder(storeBuiler)
> .withSourceName(sourceName)
> .withSourceTopic(topic)
> .withTimestampExtractor(timestampExtractor)
> .withKeyDeserializer(keyDeserializer)
> .withValueDeserializer(valueDeserializer)
> .withProcessorName(processorName)
> .withStateUpdateSupplier(stateUpdateSupplier)
> ){code}
>
> Note: new API design proposals should take into account the proposed grammar:
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams+DSL+Grammar
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
