Thanks for the excellent summary. I started my career at Oracle, where people thought about things in terms of data models. If two entities (classes) were in 1-1 correspondence and had similar attributes, they had to be merged, right?
Not so fast. Even if they are in 1-1 correspondence, they may have different purposes and be used in different contexts by different audiences. From a code standpoint, they may have different dependencies, and so integrating them would cause an undesirable increase in coupling. I think that is the case here for SqlDialect, SqlParser.Config, and SqlConformance. No arguments, though, that if the same method exists in two places we should make sure that the names are consistent. And tactical methods for integrating them (e.g. the configureParser method I suggest in https://issues.apache.org/jira/browse/CALCITE-3050 <https://issues.apache.org/jira/browse/CALCITE-3050>) will cause them to grow closer over time. Julian > On May 7, 2019, at 7:52 PM, Yuzhao Chen <[email protected]> wrote: > > Hi guys, recently there is a issue that want to integrate SqlDialect and > SqlParser.Config > The background is that there are cases that we both use the SqlDialect and > SqlParser.config, but these config items are really a mess and come confused > me a lot, so i list them there and to see if we can make some progress. > > ### SqlDialect config items > - nullCollation: null values collation > - dataTypeSystem: type system to implement specific data types > - identifierQuoteString: starting quoting charactor > - identifierEndQuoteString: end quoting charactor > - DatabaseProduct: The name really confuse me ? Insn't it just a SqlDialect ? > - identifierEscapedQuote: escape quote for identifierQuoteString > > ### SqlParser.Config config items > - identifierMaxLength: max length of an identifier > - quotedCasing: casing of quoted identifier > - unquotedCasing: casing of unquoted identifier > - quoting: quoting charactor > - caseSensitive: if to parse the sql case sensitively > - parserFactory: a parser factory to profuce the parser > - SqlConformance: The name really confuse me ? Insn't it just a SqlDialect ? > > ### SqlConformance config items > - isLiberal: Whether this dialect supports features from a wide variety of > dialects > - isGroupByAlias: group by column alias > - isGroupByOrdinal: group by column ordinal > - isHavingAlias: is having by column alias > - isSortByOrdinal: sort by column ordinal > - isSortByAlias: sort by column alias > - isSortByAliasObscures: Whether "empno" is invalid in "select empno as x > from emp order by empno" > - isFromRequired: Whether FROM clause is required in a SELECT statement > - isBangEqualAllowed: Whether the bang-equal token != is allowed as an > alternative to <> in the parser > - isPercentRemainderAllowed: Whether the "%" operator is allowed by the > parser as an alternative to the mod function > - isMinusAllowed: Whether MINUS is allowed as an alternative to EXCEPT in the > parser > - isApplyAllowed() > - ...omitted > > We can almost see the the SqlDialect mainly controls how we access other > datasources(the runtime config), the SqlParser.Config mainly controls the > behavior of sql parsing(so we can mostly see the keywords xxxAllowed). > > Altough the 2 config class aims to different use cases, the both belong to > the concept of "SqlDialect", so i want to see if we can unify them, a > SqlDialect config controls everything. In CALCITE-3016 [2], we are planning > to introduce SqlFlavor which still represent a "SqlDialect", now we have > SqlDialect/SqlConformance/DatabaseProduct/SqlFlavor, these classes really > confused me a lot. > > So let's just have a discussion about how to re-orginize them or how we can > do them berrer :) > > [1] https://issues.apache.org/jira/browse/CALCITE-3050 > [2] https://issues.apache.org/jira/browse/CALCITE-3016 > > > Best, > Danny Chan
