You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Mike Hinchey <hi...@gmail.com> on 2015/11/12 09:42:33 UTC

Parsing DDL

Hello.  I'm having pretty good success so far using calcite to be the
driver for my database adapter.

I see in CALCITE-852, Julian added SqlKind for DDL and the , but not parser
support.  And the commits for phoenix has parser support for create view
and commit.

Do you plan for calcite to have the syntax and parser support for DDL
(especially create table and view) at some point?  I want my database to
handle standard "create table" instead of exposing my internal mechanism.

If I wanted to work on this, would those phoenix commits be a good place to
start?  That is, do that work directly in calcite?

Thanks,
Mike

Re: Parsing DDL

Posted by Jacques Nadeau <ja...@apache.org>.
Hehe.

I added some comments to CALCITE-707 that are similar to what Julian just
said.

On Thu, Nov 12, 2015 at 5:18 PM, Julian Hyde <jh...@apache.org> wrote:

> Mike,
>
> As you noticed, in https://issues.apache.org/jira/browse/CALCITE-852 we
> added support for DDL, and added a test with a COMMIT that performs a no-op.
>
> We added values CREATE_TABLE and similar values to SqlKind not because we
> thought we’d implement those commands any time soon, but because Phoenix is
> representing the AST using SqlCall objects and it really helps if those
> objects have a distinguishing SqlKind value. SqlKind is an enum, it is
> impossible for Phoenix to add new values.
>
> I’m wary about adding parsing of DDL statements to core Calcite. First,
> even core DDL comments like CREATE TABLE are much less standardized; a
> project based on Calcite, such as Phoenix would very likely need to
> override with its own syntax. Second, DDL causes changes to the model, and
> Calcite has nowhere to store those changes (the model SPI is read-only).
>
> However, I logged https://issues.apache.org/jira/browse/CALCITE-707 a
> while ago, and would like to get to it at some point. Maybe we’d write a
> DDL script that can be replayed when the server re-starts (similar to what
> hsqldb does). Or maybe we’d write a DDL handler that no-ops everything.
>
> For now, Phoenix’s approach is sound. In your project, do something
> similar to my
> https://github.com/julianhyde/phoenix/commits/1706-ddl-skeleton <
> https://github.com/julianhyde/phoenix/commits/1706-ddl-skeleton> patch,
> then adapt what they have done for CREATE VIEW into your CREATE TABLE
> command.
>
> > On Nov 12, 2015, at 10:18 AM, James Taylor <ja...@apache.org>
> wrote:
> >
> > We'd love it over in Phoenix-land if Calcite had support for parsing DDL.
>
> James,
>
> Conversely, we’d love it if you contributed your work to Calcite. I see
> you’ve added CREATE VIEW already - we’d be happy to accept that and
> anything else you do!
>
> Julian
>
>

Re: Parsing DDL

Posted by Julian Hyde <jh...@apache.org>.
Mike,

As you noticed, in https://issues.apache.org/jira/browse/CALCITE-852 we added support for DDL, and added a test with a COMMIT that performs a no-op.

We added values CREATE_TABLE and similar values to SqlKind not because we thought we’d implement those commands any time soon, but because Phoenix is representing the AST using SqlCall objects and it really helps if those objects have a distinguishing SqlKind value. SqlKind is an enum, it is impossible for Phoenix to add new values.

I’m wary about adding parsing of DDL statements to core Calcite. First, even core DDL comments like CREATE TABLE are much less standardized; a project based on Calcite, such as Phoenix would very likely need to override with its own syntax. Second, DDL causes changes to the model, and Calcite has nowhere to store those changes (the model SPI is read-only).

However, I logged https://issues.apache.org/jira/browse/CALCITE-707 a while ago, and would like to get to it at some point. Maybe we’d write a DDL script that can be replayed when the server re-starts (similar to what hsqldb does). Or maybe we’d write a DDL handler that no-ops everything.

For now, Phoenix’s approach is sound. In your project, do something similar to my https://github.com/julianhyde/phoenix/commits/1706-ddl-skeleton <https://github.com/julianhyde/phoenix/commits/1706-ddl-skeleton> patch, then adapt what they have done for CREATE VIEW into your CREATE TABLE command.

> On Nov 12, 2015, at 10:18 AM, James Taylor <ja...@apache.org> wrote:
> 
> We'd love it over in Phoenix-land if Calcite had support for parsing DDL.

James,

Conversely, we’d love it if you contributed your work to Calcite. I see you’ve added CREATE VIEW already - we’d be happy to accept that and anything else you do!

Julian


Re: Parsing DDL

Posted by James Taylor <ja...@apache.org>.
Hi Mike,
We'd love it over in Phoenix-land if Calcite had support for parsing DDL.
We'd probably need to plug-in a few extensions specific to Phoenix grammar,
but we could do that with the existing template mechanism over in the
Phoenix code base.
Thanks,
James

On Thu, Nov 12, 2015 at 12:42 AM, Mike Hinchey <hi...@gmail.com> wrote:

> Hello.  I'm having pretty good success so far using calcite to be the
> driver for my database adapter.
>
> I see in CALCITE-852, Julian added SqlKind for DDL and the , but not parser
> support.  And the commits for phoenix has parser support for create view
> and commit.
>
> Do you plan for calcite to have the syntax and parser support for DDL
> (especially create table and view) at some point?  I want my database to
> handle standard "create table" instead of exposing my internal mechanism.
>
> If I wanted to work on this, would those phoenix commits be a good place to
> start?  That is, do that work directly in calcite?
>
> Thanks,
> Mike
>