>From a user's perspective, I prefer the shorter one "format=json", because it's more concise and straightforward. The "kind" is redundant for users. Is there a real case requires to represent the configuration in JSON style? As far as I can see, I don't see such requirement, and everything works fine by now.
So I'm in favor of "format=json". But if the community insist to follow code style on this, I'm also fine with the longer one. Btw, I also CC user mailing list to listen more user's feedback. Because I think this is relative to usability. Best, Jark On Wed, 29 Apr 2020 at 22:09, Chesnay Schepler <ches...@apache.org> wrote: > > Therefore, should we advocate instead: > > > > 'format.kind' = 'json', > > 'format.fail-on-missing-field' = 'false' > > Yes. That's pretty much it. > > This is reasonable important to nail down as with such violations I > believe we could not actually switch to a standard YAML parser. > > On 29/04/2020 16:05, Timo Walther wrote: > > Hi everyone, > > > > discussions around ConfigOption seem to be very popular recently. So I > > would also like to get some opinions on a different topic. > > > > How do we represent hierarchies in ConfigOption? In FLIP-122, we > > agreed on the following DDL syntax: > > > > CREATE TABLE fs_table ( > > ... > > ) WITH ( > > 'connector' = 'filesystem', > > 'path' = 'file:///path/to/whatever', > > 'format' = 'csv', > > 'format.allow-comments' = 'true', > > 'format.ignore-parse-errors' = 'true' > > ); > > > > Of course this is slightly different from regular Flink core > > configuration but a connector still needs to be configured based on > > these options. > > > > However, I think this FLIP violates our code style guidelines because > > > > 'format' = 'json', > > 'format.fail-on-missing-field' = 'false' > > > > is an invalid hierarchy. `format` cannot be a string and a top-level > > object at the same time. > > > > We have similar problems in our runtime configuration: > > > > state.backend= > > state.backend.incremental= > > restart-strategy= > > restart-strategy.fixed-delay.delay= > > high-availability= > > high-availability.cluster-id= > > > > The code style guide states "Think of the configuration as nested > > objects (JSON style)". So such hierarchies cannot be represented in a > > nested JSON style. > > > > Therefore, should we advocate instead: > > > > 'format.kind' = 'json', > > 'format.fail-on-missing-field' = 'false' > > > > What do you think? > > > > Thanks, > > Timo > > > > [1] > > > https://flink.apache.org/contributing/code-style-and-quality-components.html#configuration-changes > > > >