[
https://issues.apache.org/jira/browse/FLINK-29379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17617096#comment-17617096
]
Piotr Nowojski commented on FLINK-29379:
----------------------------------------
I would propose to start with an intermediate step. Keep the
{{ExecutionConfig}} public methods as they are, but just back the setters and
getters via a {{Configuration ExecutionConfig#configuration}} field. All the
setters/getters could go through that {{configuration}} field. Thanks to that
we don't need to touch how users and Flink itself is interacting with the
{{ExecutionConfig}} for the time being. And this would allow us to produce nice
error message for
{{org.apache.flink.configuration.DeploymentOptions#PROGRAM_CONFIG_ENABLED}}
violations.
Later this can easily lead to the Option B that [~twalthr] mentioned. WDYT?
> Back ExecutionConfig and CheckpointConfig by Configuration
> ----------------------------------------------------------
>
> Key: FLINK-29379
> URL: https://issues.apache.org/jira/browse/FLINK-29379
> Project: Flink
> Issue Type: Improvement
> Components: API / DataStream
> Reporter: Timo Walther
> Assignee: Piotr Nowojski
> Priority: Major
>
> Not sure if this is a duplicate, but as this issue pops up over and over
> again, it might be time to discuss it here and fix it.
> Currently, configuration is spread across instances of {{Configuration}} and
> POJOs (e.g. {{ExecutionConfig}} or {{CheckpointConfig}}). This makes it very
> tricky to handle configuration throughout the stack. The practice has shown
> that configuration might be passed, layered, merged, restricted, copied,
> filtered, etc. This is easy with the config option stack but very tricky with
> the existing POJOs. Esp. it is difficult to keep the two in sync or compare
> them.
> Many locations reveal the current shortcoming. For example,
> {{org.apache.flink.table.planner.delegation.DefaultExecutor}} has a
> {{isCheckpointingEnabled()}} method simply because we cannot trust the
> {{Configuration}} object that is passed around. Same for checking if object
> reuse is enabled.
> A solution is still up for discussion. Ideally, we deprecate
> {{ExecutionConfig}} and {{CheckpointConfig}} and advocate a pure config
> option based approach. Alternatively, we could do a hybrid approach similar
> to `TableConfig` (that is backed by config options but has setters for
> convenience). The latter approach would cause less deprecations in the API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
