In order to allow reading and writing of configuration from a file or string-based properties. We should consider removing TableConfig and fully rely on a Configuration-based object with ConfigOptions.
This effort was partially already started which is why TableConfig.getConfiguration exists.
However, we should clarify if we would like to have control and traceability over layered configurations such as flink-conf,yaml < StreamExecutionEnvironment < TableEnvironment < Query. Maybe the Configuration class is not the right abstraction for this.
Note: The following TableConfig options are not preserved:
- nullCheck: Flink will automatically enable null checks based on the table schema (NOT NULL property)
- decimalContext: this configuration is only used by the legacy planner which will be removed in one of the next releases
- maxIdleStateRetention: is automatically derived as 1.5* idleStateRetention until StateTtlConfig is fully supported (at which point only a single parameter is required).