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.
