The best way to learn this stuff is to run JdbcAdapterTest in a debugger. You will see that the SqlDialect is deduced from the product name etc. that come out of the JDBC driver.
Yes, Calcite “optimizes” the query. It parses the SQL, converts the AST to RelNodes, and applies rules to convert as many of those RelNodes into JDBC RelNodes, based on the capabilities of the target database. Then that tree is converted back to SQL, based on the dialect. There isn’t extensive documentation. This is a framework, and the number of users ~~ the number of developers. So the users have to be self-starting. Julian > On Mar 15, 2017, at 6:39 PM, [email protected] wrote: > > Hi Julian, > > Thanks for the information and direction. I did some reading and here are > couple more questions: > > 1. It seems to me that the “conformance” property is for different SQL > standards (e.g. PRAGMATIC_2003, STRICT_92) or Oracle (ORACLE_10, ORACLE_12). > For a specific database that I am migrating off (e.g. greenplum), what value > should be set for “conformance” or do we need to add a customized > implementation to support database specific SQL syntax and functions? > 2. For SQL dialect, where SQL dialect is set? I don’t see it is as a valid > JDBC properties. > 3. I did find a list of enum values for SQL dialect, however, is it possible > to specify the version of the target database product? Different versions of > same database product may have different level of support in terms of SQL > syntax.. > 3. As you mentioned below, this will be through JDBC adapter. When the target > database is running on Hadoop (e.g. Hive), after parsing SQL, does Calcite > JDBC do query optimization? or it just generates Hive QL and then push down > to Hive for query optimization and execution? > > I am new to Calcite and sorry if these are too detail for a dev mailing list. > I didn’t find detail architecture diagrams/documents online and haven’t gone > through source codes yet… > > Thanks > Herman > > >> On Mar 13, 2017, at 23:17, Julian Hyde <[email protected]> wrote: >> >> We already have the switches you’d need: you can control the dialect >> accepted by Calcite’s parser by setting the “conformance” property [1], and >> the JDBC adapter generates SQL appropriate for the target database by >> inferring the target database's “dialect” [2]. >> >> What’s missing is a lot of testing of the various combinations of source and >> target dialects. >> >> Julian >> >> >> [1] >> https://calcite.apache.org/apidocs/org/apache/calcite/sql/validate/SqlConformance.html >> >> <https://calcite.apache.org/apidocs/org/apache/calcite/sql/validate/SqlConformance.html> >> >> [2] >> https://calcite.apache.org/apidocs/org/apache/calcite/sql/SqlDialect.html >> <https://calcite.apache.org/apidocs/org/apache/calcite/sql/SqlDialect.html> >> >>> On Mar 13, 2017, at 8:11 PM, [email protected] wrote: >>> >>> I am thinking Calcite should be helpful for a SQL migration (making SQL >>> wrote for database A work with database B, includes SQL syntax and >>> potential query optimization), I am new to Calcite and this mailing list, >>> I’d appreciate if anyone here can help point me to a direction where to >>> start. >>> >>> Thanks >>> Herman >>> >>> >> >
