Hi, I think it’s important to keep in mind the original goals of this FLIP and not let the scope grow indefinitely. As I recall it, the goals are:
- Extend the ConfigOption system enough to allow the Table API to configure options that are right now only available on CheckpointingOptions, ExecutionConfig, and StreamExecutionEnvironment. We also want to do this without manually having to “forward” all the available configuration options by introducing equivalent setters in the Table API - Do the above while keeping in mind that eventually we want to allow users to configure everything from either the flink-conf.yaml, vie command line parameters, or via a Configuration. I think the FLIP achieves this, with the added side goals of making validation a part of ConfigOptions, making them type safe, and making the validation constraints documentable (via automatic doc generation.) All this without breaking backwards compatibility, if I’m not mistaken. I think we should first agree what the basic goals are so that we can quickly converge to consensus on this FLIP because it blocks other people/work. Among other things FLIP-59 depends on this. What are other opinions that people have? I know Becket at least has some thoughts about immutability and loading objects via the configuration but maybe they could be put into a follow-up FLIP if they are needed. Also, I had one thought on the interaction of this FLIP-54 and FLIP-59 when it comes to naming. I think eventually it makes sense to have a common interface for things that are configurable from a Configuration (FLIP-59 introduces the first batch of this). It seems natural to call this interface Configurable. That’s a problem for this FLIP-54 because we also introduce a Configurable. Maybe the thing that we introduce here should be called ConfigObject or ConfigStruct to highlight that it has a more narrow focus and is really only a POJO for holding a bunch of config options that have to go together. What do you think? Best, Aljoscha > On 3. Sep 2019, at 14:08, Timo Walther <twal...@apache.org> wrote: > > Hi Danny, > > yes, this FLIP covers all the building blocks we need also for unification of > the DDL properties. > > Regards, > Timo > > > On 03.09.19 13:45, Danny Chan wrote: >>> with the new SQL DDL >> based on properties as well as more connectors and formats coming up, >> unified configuration becomes more important >> >> I Cann’t agree more, do you think we can unify the config options key format >> here for all the DDL properties ? >> >> Best, >> Danny Chan >> 在 2019年8月16日 +0800 PM10:12，dev@flink.apache.org，写道： >>> with the new SQL DDL >>> based on properties as well as more connectors and formats coming up, >>> unified configuration becomes more important > >
