You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by "Timo Walther (Jira)" <ji...@apache.org> on 2022/09/21 09:11:00 UTC

[jira] [Created] (FLINK-29379) Back ExecutionConfig and CheckpointConfig by Configuration

Timo Walther created FLINK-29379:
------------------------------------

             Summary: 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


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 is 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.

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)