[ 
https://issues.apache.org/jira/browse/FLINK-16835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142100#comment-17142100
 ] 

Jark Wu edited comment on FLINK-16835 at 6/22/20, 2:30 PM:
-----------------------------------------------------------

I'm fine wht current configuration keys, they may happen in optimizer and 
runtime, except the state ttl which should be prefixed with {{table.exec}}.

Regarding to {{table.exec.state.ttl}}, yes, it defines the min retention and 
the max retention can be derived from it (by 1.5x?) We can add an explanation 
for the multiplier in documentation before we fully switch to 
{{StateTtlConfig}}. What do you think?


was (Author: jark):
I'm fine wht current configuration keys, they may happen in optimizer and 
runtime, except the state ttl which should be prefixed with {{table.exec}}.

Regarding to {{table.exec.state.ttl}}, yes, it defines the min retention and 
the max retention can be derived from it (by 1.5x?) We can add a explain for 
the multiplier in documentation before we fully switch to {{StateTtlConfig}}. 
What do you think?

> Replace TableConfig with Configuration
> --------------------------------------
>
>                 Key: FLINK-16835
>                 URL: https://issues.apache.org/jira/browse/FLINK-16835
>             Project: Flink
>          Issue Type: Improvement
>          Components: Table SQL / API
>            Reporter: Timo Walther
>            Priority: Major
>
> 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. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to