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

["Piotr Nowojski (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FLINK-29379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Piotr Nowojski reassigned FLINK-29379:
--------------------------------------

    Assignee: Piotr Nowojski

> 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)