calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <julianh...@gmail.com>
Subject Re: Calcite supporting DDL
Date Thu, 30 Apr 2015 18:58:32 GMT
Good stuff, Jacques. Thanks for sharing. I already copied your parser extensions into Phoenix.
:) And I’ll suggest that they follow your model for AST nodes.

I’d like to introduce some base classes into Calcite (maybe similar to your DrillSqlCall)
to make it easier to write DDL. I’ll try to make it compatible with what you’ve already
done.

Julian


On Apr 30, 2015, at 10:23 AM, Jacques Nadeau <jacques@apache.org> wrote:

> For create/drop view, show tables, use schema, etc, you can grab all the
> code from Drill:
> 
> grammar:
> 
> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/codegen/includes/parserImpls.ftl
> 
> sqlcalls:
> 
> https://github.com/apache/drill/tree/master/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/parser
> 
> 
> On Thu, Apr 30, 2015 at 10:21 AM, Julian Hyde <julian@hydromatic.net> wrote:
> 
>> OK, great. Can you drive this by submitting pull requests.
>> 
>>> On Apr 30, 2015, at 12:54 AM, Xavier Leong <leongxfh@persistent.com>
>> wrote:
>>> 
>>> Thanks Julian for the insight of Calcite path. My colleague just opened
>> JIRA for supporting DML (705) and DDL (706).
>>> 
>>> We can work together to accomplish the common goal, thanks.
>>> 
>>> +1 for DML support, as it will solve the gaps in statement execute()
>> call differentiating a DQL preparedStatement vs a DML preparedStatement.
>>> 
>>> 
>>> -----Original Message-----
>>> From: Julian Hyde [mailto:julian@hydromatic.net]
>>> Sent: Thursday, April 30, 2015 1:23 AM
>>> To: dev@calcite
>>> Subject: Re: Calcite supporting DDL
>>> 
>>> I would like Calcite to support simple DDL.
>>> 
>>> DDL (and other commands such as KILL STATEMENT) make it possible to do a
>> wide range of operations over a REST or JDBC interface. We can't expect
>> everything do be done locally, using Java method calls.
>>> 
>>> I expect that projects that use Calcite will define their own DDL. (In
>> fact Drill and Phoenix already do; see
>>> https://issues.apache.org/jira/browse/PHOENIX-1706.) Those projects are
>> very likely to have their own variations on CREATE TABLE etc. so they will
>> want to extend the parser. What I did in Phoenix (which was in turn adapted
>> from Drill) is a model that other projects can follow.
>>> 
>>> But the base Calcite project should have CREATE TABLE, DROP TABLE,
>> CREATE SCHEMA, DROP SCHEMA, CREATE [ OR REPLACE ] VIEW etc. There will be
>> an AST (extending SqlNode) for each of these commands, and a
>> command-handler. Each project that uses Calcite could extend those ASTs,
>> but it would be fine if it built its own AST and command-handler.
>>> 
>>> On Wed, Apr 29, 2015 at 1:11 AM, Xavier Leong <leongxfh@persistent.com>
>> wrote:
>>>> Dear commiters, as the root schema can be immutable and change during
>> run time, it is possible to have DDL to change the schema, create tables,
>> view, or alter tables. Like to know if this part of the roadmap to support
>> DDL, or is it up to the storage layer (adapter) to handles schema changes
>> via other SPI.
>>>> 
>>>> Thanks.
>>>> 
>>>> DISCLAIMER
>>>> ==========
>>>> This e-mail may contain privileged and confidential information which
>> is the property of Persistent Systems Ltd. It is intended only for the use
>> of the individual or entity to which it is addressed. If you are not the
>> intended recipient, you are not authorized to read, retain, copy, print,
>> distribute or use this message. If you have received this communication in
>> error, please notify the sender and delete all copies of this message.
>> Persistent Systems Ltd. does not accept any liability for virus infected
>> mails.
>>>> 
>>> 
>>> DISCLAIMER
>>> ==========
>>> This e-mail may contain privileged and confidential information which is
>> the property of Persistent Systems Ltd. It is intended only for the use of
>> the individual or entity to which it is addressed. If you are not the
>> intended recipient, you are not authorized to read, retain, copy, print,
>> distribute or use this message. If you have received this communication in
>> error, please notify the sender and delete all copies of this message.
>> Persistent Systems Ltd. does not accept any liability for virus infected
>> mails.
>>> 
>> 
>> 


Mime
View raw message