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. >
