OK, great. Can you drive this by submitting pull requests.
> On Apr 30, 2015, at 12:54 AM, Xavier Leong <[email protected]> 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:[email protected]]
> 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 <[email protected]> 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.
>
