[
https://issues.apache.org/jira/browse/FLINK-16835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141997#comment-17141997
]
Fabian Hueske commented on FLINK-16835:
---------------------------------------
{quote} # Maybe we can remove the NULL_CHECK configuration. I guess it is never
used by users and we are going to refactor code generation to remove null check
when the type is NOT NULL automatically.{quote}
Sounds good to me
{quote} # I'm thinking to merge {{table.idle-state.retention.min}} and
{{table.idle-state.retention.max}} into one configuration, e.g.
{{table.exec.state.ttl}}. Sometimes this configuration is a bit confusing that
what's the max/min is used for. Besides, we are moving to use
{{StateTtlConfig}} which is more lightweight than cleanup timers and can
decouple state cleanup from operator logic.
{quote}
So we would only set the min retention time and derive the max retention time
by adding a constant (or value that's relative to the min retention time)? As
long as the switch to {{StateTtlConfig}} isn't completed yet, we would need to
set two durations.
{quote} # The value of {{MathContext.DECIMAL128.toString()}} is {{precision=34
roundingMode=HALF_EVEN}} which is rather hard to configure. Could we provide
some predefined enums, e.g. {{DECIMAL128, DECIMAL64, DECIMAL32, UNLIMITED}}. We
can support custom decimal context in the future when it is needed.
{quote}
Sounds good to me as well.
What do you think about the configuration keys?
Are they OK or should we change the prefix from {{table}} to {{table.exec}} ?
> 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)
