[jira] [Commented] (CALCITE-707) Built-in support for simple DDL statements
[ https://issues.apache.org/jira/browse/CALCITE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254334#comment-16254334 ] Julian Hyde commented on CALCITE-707: - Hope so. Just trying to get CREATE MATERIALIZED VIEW working. > Built-in support for simple DDL statements > -- > > Key: CALCITE-707 > URL: https://issues.apache.org/jira/browse/CALCITE-707 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > 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 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. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-707) Built-in support for simple DDL statements
[ https://issues.apache.org/jira/browse/CALCITE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252870#comment-16252870 ] Shuyi Chen commented on CALCITE-707: Do you think this can make it to the 1.15 release? > Built-in support for simple DDL statements > -- > > Key: CALCITE-707 > URL: https://issues.apache.org/jira/browse/CALCITE-707 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > 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 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. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-707) Built-in support for simple DDL statements
[ https://issues.apache.org/jira/browse/CALCITE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248274#comment-16248274 ] Julian Hyde commented on CALCITE-707: - I am actively working on this and CALCITE-1991, creating a new "server" module. You can see work in progress in https://github.com/julianhyde/calcite/tree/707-ddl. > Built-in support for simple DDL statements > -- > > Key: CALCITE-707 > URL: https://issues.apache.org/jira/browse/CALCITE-707 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > 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 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. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-707) Built-in support for simple DDL statements
[ https://issues.apache.org/jira/browse/CALCITE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003344#comment-15003344 ] Jacques Nadeau commented on CALCITE-707: Julian, it seems like maybe we can make some of these things separate grammar modules rather than in core. That way people can pick and choose what portion of the grammar they want to use. Since we already have the extension mechanism, it seems like it would be easy to add these externally. My thought is that it is currently weird that we currently have two failure scenarios when building a tool on top of this: 1. User uses sql that is valid (but engine doesn't support) 2. User uses invalid sql. Ideally, the user should have the same experience in either of these. By slimstreaming everything into a single grammar, that means the user doesn't get the same experience. I'd like to treat much of this grammar as modular. For example, each of the statements you describe in the description could be its own set of files. We'd have an Extended maven module which incorporates all of them. However, a user could also use just the core or could pick and select inclusion of only some of the clauses. This would also help protect against weird scenarios like the extends/table function situation we have for Drill right now where one set of contributors adds extended grammar and that conflicts with another user's extended grammar. These things can be resolved but I don't think the grammar should require things. > Built-in support for simple DDL statements > -- > > Key: CALCITE-707 > URL: https://issues.apache.org/jira/browse/CALCITE-707 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > 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 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
