[
https://issues.apache.org/jira/browse/FLINK-29379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Nowojski updated FLINK-29379:
-----------------------------------
Summary: Back (most of the) ExecutionConfig and CheckpointConfig by
Configuration (was: Back ExecutionConfig and CheckpointConfig by Configuration)
> Back (most of the) 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
> Labels: pull-request-available
> Fix For: 1.17.0
>
>
> 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)
