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

Piotr Nowojski closed FLINK-29379.
----------------------------------
    Resolution: Fixed

Most of the {{CheckpointConfig}} migrated to {{Configuration}} in 
e98e289991b..bb124f4ada4

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

Reply via email to