Thanks Julian. appreciate the insights… Herman.
> On Mar 16, 2017, at 21:08, Julian Hyde <[email protected]> wrote:
>
> 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
>>>>
>>>>
>>>
>>
>
