[
https://issues.apache.org/jira/browse/KAFKA-20279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18065639#comment-18065639
]
Young Joo Kim commented on KAFKA-20279:
---------------------------------------
Hi [~mjsax]
I've been looking into this and wanted to confirm my approach before submitting
a PR.
Currently, AbstractConfigurableStoreFactory#configure() only sets the format to
HEADERS when explicitly configured, leaving it null otherwise. Each subclass
then independently decides the default in builder():
- KeyValueStoreMaterializer: defaults to TIMESTAMPED, forces HEADERS when set
- WindowStoreMaterializer / SlidingWindowStoreMaterializer: defaults to
TIMESTAMPED
- StreamJoinedStoreFactory: defaults to PLAIN
- OuterStreamJoinStoreFactory: defaults to PLAIN, forces HEADERS when set
- SubscriptionStoreFactory: defaults to TIMESTAMPED, forces HEADERS when set
To make the factory "dumb", I'm considering having each subclass provide its
default format (e.g., via a defaultStoreFormat() method), so that configure()
resolves the format completely — eliminating null and removing the decision
logic from builder().
Does this align with what you had in mind, or were you thinking of a different
approach (e.g., passing the resolved format from the DSL operator code that
creates the factory)?
> Refactor `AbstractConfigurableStoreFactory#dslStoreFormat()`
> ------------------------------------------------------------
>
> Key: KAFKA-20279
> URL: https://issues.apache.org/jira/browse/KAFKA-20279
> Project: Kafka
> Issue Type: Sub-task
> Reporter: Matthias J. Sax
> Assignee: Young Joo Kim
> Priority: Minor
>
> Atm, we track the configured DSL store format via `
> AbstractConfigurableStoreFactory#dslStoreFormat()` and sub-classe make
> decision about how to translate the provided format, in particular what the
> default is they are using if not set.
>
> This works atm, but doesn't seem correct. The factory does not know, which
> DSL operator (aka Processor implementation) uses it. We should make the
> factory "dumb" and pull out this decision to the code that _uses_ the
> factory, as only the creator of the factory has the context to make the right
> decision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)