Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-707

Built-in support for simple DDL statements

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          julianhyde Julian Hyde added a comment -

          Hope so. Just trying to get CREATE MATERIALIZED VIEW working.

          Show
          julianhyde Julian Hyde added a comment - Hope so. Just trying to get CREATE MATERIALIZED VIEW working.
          Hide
          suez1224 Shuyi Chen added a comment -

          Do you think this can make it to the 1.15 release?

          Show
          suez1224 Shuyi Chen added a comment - Do you think this can make it to the 1.15 release?
          Hide
          julianhyde Julian Hyde added a comment -

          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.

          Show
          julianhyde Julian Hyde added a comment - 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 .
          Hide
          julianhyde Julian Hyde added a comment -

          I think it's really likely that Project X and Project Y will have different syntax for CREATE TABLE. If we put it into core we'd spend ages figuring out how projects can override CREATE TABLE without overriding DROP TABLE and CREATE INDEX. And I haven't yet heard anyone volunteer to contribute CREATE TABLE to calcite.

          Show
          julianhyde Julian Hyde added a comment - I think it's really likely that Project X and Project Y will have different syntax for CREATE TABLE. If we put it into core we'd spend ages figuring out how projects can override CREATE TABLE without overriding DROP TABLE and CREATE INDEX. And I haven't yet heard anyone volunteer to contribute CREATE TABLE to calcite.
          Hide
          jnadeau Jacques Nadeau added a comment -

          Why isn't this one of them? I'm thinking I' missing something in what you're saying.

          If someone wants CREATE TABLE, why can't they simply depend on a calcite jar which has the grammar implementation and incorporate it into their custom parser compilation?

          Show
          jnadeau Jacques Nadeau added a comment - Why isn't this one of them? I'm thinking I' missing something in what you're saying. If someone wants CREATE TABLE, why can't they simply depend on a calcite jar which has the grammar implementation and incorporate it into their custom parser compilation?
          Hide
          julianhyde Julian Hyde added a comment -

          Yes. There are times when you can achieve re-use using elegant inheritance and so forth. This is not one of them. If project X wants CREATE TABLE, it should copy-paste from project Y's CREATE TABLE.

          Show
          julianhyde Julian Hyde added a comment - Yes. There are times when you can achieve re-use using elegant inheritance and so forth. This is not one of them. If project X wants CREATE TABLE, it should copy-paste from project Y's CREATE TABLE.
          Hide
          jnadeau Jacques Nadeau added a comment -

          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.

          Show
          jnadeau Jacques Nadeau added a comment - 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.

            People

            • Assignee:
              julianhyde Julian Hyde
              Reporter:
              julianhyde Julian Hyde
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:

                Development