You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Vladimir Ozerov <vo...@gridgain.com> on 2017/01/27 12:06:10 UTC
Do not use H2 parser for DDL
Folks,
H2 has nice and powerful SQL parser, and we pass all incoming SQL commands
through it. However it doesn't support custom SQL syntax, which we are
likely to need in DDL at some point in future.
As DDL statements are relatively easy to parse comparing to SELECTs and
they do not involve optimizer, we can easily create object model of DDL
command without invoking H2 at all.
I propose to introduce small change into our parsing logic as follows:
if (req.startsWith("CREATE" or "ALTER" or "DELETE")
parseDdlManually(req);
else
parseWithH2(req);
It should be enough to support any custom syntax for our DDL with any
limitations and without any dependencies on H2 folks.
For instance, see H2 "CREATE TABLE" [1] and "CREATE INDEX" [2] structure.
It is already very simple. But provided that Ignite doesn't support most of
H2 DDL features, Ignite DDL structure will be even simpler.
it should take no more than 1-2 days to implement fully-fledged parsing for
these two commands.
Thoughts?
Vladimir.
[1] http://www.h2database.com/html/grammar.html#create_table
[2] http://www.h2database.com/html/grammar.html#create_index
Re: Do not use H2 parser for DDL
Posted by Sergi Vladykin <se...@gmail.com>.
IMO the right thing is not to divide between "us" and "them". We use H2
anyways and if we improve usability in H2, we automatically improve
usability in Ignite.
Sergi
2017-02-06 11:27 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> Sergi,
>
> Cache creation function will be too complex without named parameters. As I
> understand we have two options at the moment:
> - Invest into H2 and add named parameters there, then use custom functions
> in Ignite;
> - Invest into Ignite and add custom "CREATE CACHE" parsing.
>
> CREATE CACHE doesn't appear to be extraordinary complex to me, especially
> for the first release, where there will be no need to parse absolutely
> every single property. So choosing between these two options my vote is for
> putting efforts to Ignite rather than to H2.
>
> On Fri, Feb 3, 2017 at 5:56 PM, Sergi Vladykin <se...@gmail.com>
> wrote:
>
> > Nope, but we can add this to H2 to make it compatible with Oracle [1]
> > and/or PostgreSQL [2].
> >
> > [1]
> > https://logicalread.com/oracle-11g-named-parameters-
> > in-sql-function-calls-mc02
> > [2] https://www.postgresql.org/docs/9.1/static/sql-syntax-
> > calling-funcs.html
> >
> > Sergi
> >
> > 2017-02-03 17:41 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> >
> > > Sergi,
> > >
> > > Does H2 support naming for function parameters? E.g. NEW_CACHE(backups:
> > 1,
> > > mode: PARTITIONED)
> > >
> > > On Fri, Feb 3, 2017 at 4:28 PM, Sergi Vladykin <
> sergi.vladykin@gmail.com
> > >
> > > wrote:
> > >
> > > > Actually we do not support FULLTEXT indexes in SQL right now. Thus I
> > > think
> > > > we will have to postpone this feature anyways.
> > > >
> > > > I hope that H2 Mode will solve most of the problems here. But another
> > > thing
> > > > is that IMO we should avoid inventing any "too custom" SQL syntax.
> For
> > > > example I agree that we have to be able to create caches from SQL,
> but
> > I
> > > > don't like the idea of inventing CREATE CACHE syntax. May be its
> better
> > > to
> > > > have functions like the following:
> > > >
> > > > CALL NEW_CACHE(...);
> > > >
> > > > This is very straightforward and will allow us to avoid any problems
> > with
> > > > syntax parsing.
> > > >
> > > > Sergi
> > > >
> > > > 2017-01-30 12:47 GMT+03:00 Alexander Paschenko <
> > > > alexander.a.paschenko@gmail.com>:
> > > >
> > > > > Dima,
> > > > >
> > > > > H2's grammar for CREATE INDEX currently does not allow expressing
> all
> > > > > that Ignite has in this field - say, I can't specify FULLTEXT index
> > > > > types. (But, for clarity, I should also note that I don't see
> > anything
> > > > > else missing right away).
> > > > >
> > > > > On the other hand, if we want to enhance indexes someday, H2 may
> not
> > > > > be there to support our custom syntax.
> > > > >
> > > > > All in all, I believe that the moment for messing the custom syntax
> > > > > will no doubt come, sooner or later, and we can't avoid it forever.
> > So
> > > > > all our attempts to avoid messing with it now just delay the moment
> > > > > when we will simply have no choice and will have to come up with
> > > > > something quick and dirty in a rush and hurry.
> > > > >
> > > > > Yes, Ignite mode for H2 probably could be a solution for parsing,
> but
> > > > > we have to keep in mind that compatibility mode in H2 is more than
> > > > > syntax. And H2 folks will not likely be happy with just bunch of
> > > > > random syntax changes that are otherwise irrelevant to RDBMS and
> will
> > > > > not be used by or implemented in H2 itself anyway.
> > > > >
> > > > > - Alex
> > > > >
> > > > > 2017-01-30 4:18 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org
> >:
> > > > > > On Fri, Jan 27, 2017 at 8:51 PM, Alexander Paschenko <
> > > > > > alexander.a.paschenko@gmail.com> wrote:
> > > > > >
> > > > > >> Guys,
> > > > > >>
> > > > > >> And what would you say if I suggested that we implement custom
> > > grammar
> > > > > >> support with ANTLR? It allows you to describe pretty much any
> > > grammar
> > > > > >> in a declarative way, generates lexer and parser and then allows
> > to
> > > > > >> easily process parsed commands by implementing few (generated)
> > > > > >> interfaces. Yesterday I gave it a try and it's really simple.
> > > > > >> Downsides are use of generated code itself (I'm pretty sure
> > someone
> > > is
> > > > > >> strongly against it) and relative wordiness of resulting code
> > > written
> > > > > >> manually. But this approach will no doubt save time and allow
> any
> > > > > >> extensions or changes in syntax in the future w/o worrying about
> > H2
> > > or
> > > > > >> anyone 3rd party. Thoughts?
> > > > > >>
> > > > > >>
> > > > > > Alex,
> > > > > >
> > > > > > My preference would be to keep it simple, without introducing any
> > > > custom
> > > > > > grammar, at least for the "CREATE INDEX" command. I understand
> the
> > > need
> > > > > for
> > > > > > decoupling cache from schema, but it will take much longer to
> > > > implement,
> > > > > > and I would leave it for phase 2. In phase 1 we can focus on
> > > delivering
> > > > > > this much needed feature to the community as soon as possible.
> > > > > >
> > > > > > Do you agree?
> > > > > >
> > > > > >
> > > > > >> - Alex
> > > > > >>
> > > > > >> 2017-01-27 21:56 GMT+03:00 Vladimir Ozerov <
> vozerov@gridgain.com
> > >:
> > > > > >> > My point was that we can avoid dependency on 3rd party
> > developers
> > > > for
> > > > > >> this
> > > > > >> > relatively simple logic.
> > > > > >> >
> > > > > >> > On Fri, Jan 27, 2017 at 8:07 PM, Dmitriy Setrakyan <
> > > > > >> dsetrakyan@apache.org>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >> On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin <
> > > > > >> sergi.vladykin@gmail.com>
> > > > > >> >> wrote:
> > > > > >> >>
> > > > > >> >> > H2 to some extent supports syntax (and quirks) from other
> > > > > databases.
> > > > > >> For
> > > > > >> >> > example you can start it with MODE=MySQL and it will allow
> > some
> > > > > MySQL
> > > > > >> >> > specific syntax to be handled.
> > > > > >> >> >
> > > > > >> >> > Having said that, IMO the most correct way to handle
> > > non-standard
> > > > > >> syntax
> > > > > >> >> is
> > > > > >> >> > to introduce H2 MODE=ApacheIgnite and put the needed
> switches
> > > > > there.
> > > > > >> >> >
> > > > > >> >> > Though this needs to be negotiated with H2 folks.
> > > > > >> >> >
> > > > > >> >>
> > > > > >> >> Sergi, can you ask the H2 folks about this? I agree, this
> > sounds
> > > > like
> > > > > >> the
> > > > > >> >> most correct way.
> > > > > >> >>
> > > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Do not use H2 parser for DDL
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Sergi,
Cache creation function will be too complex without named parameters. As I
understand we have two options at the moment:
- Invest into H2 and add named parameters there, then use custom functions
in Ignite;
- Invest into Ignite and add custom "CREATE CACHE" parsing.
CREATE CACHE doesn't appear to be extraordinary complex to me, especially
for the first release, where there will be no need to parse absolutely
every single property. So choosing between these two options my vote is for
putting efforts to Ignite rather than to H2.
On Fri, Feb 3, 2017 at 5:56 PM, Sergi Vladykin <se...@gmail.com>
wrote:
> Nope, but we can add this to H2 to make it compatible with Oracle [1]
> and/or PostgreSQL [2].
>
> [1]
> https://logicalread.com/oracle-11g-named-parameters-
> in-sql-function-calls-mc02
> [2] https://www.postgresql.org/docs/9.1/static/sql-syntax-
> calling-funcs.html
>
> Sergi
>
> 2017-02-03 17:41 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
>
> > Sergi,
> >
> > Does H2 support naming for function parameters? E.g. NEW_CACHE(backups:
> 1,
> > mode: PARTITIONED)
> >
> > On Fri, Feb 3, 2017 at 4:28 PM, Sergi Vladykin <sergi.vladykin@gmail.com
> >
> > wrote:
> >
> > > Actually we do not support FULLTEXT indexes in SQL right now. Thus I
> > think
> > > we will have to postpone this feature anyways.
> > >
> > > I hope that H2 Mode will solve most of the problems here. But another
> > thing
> > > is that IMO we should avoid inventing any "too custom" SQL syntax. For
> > > example I agree that we have to be able to create caches from SQL, but
> I
> > > don't like the idea of inventing CREATE CACHE syntax. May be its better
> > to
> > > have functions like the following:
> > >
> > > CALL NEW_CACHE(...);
> > >
> > > This is very straightforward and will allow us to avoid any problems
> with
> > > syntax parsing.
> > >
> > > Sergi
> > >
> > > 2017-01-30 12:47 GMT+03:00 Alexander Paschenko <
> > > alexander.a.paschenko@gmail.com>:
> > >
> > > > Dima,
> > > >
> > > > H2's grammar for CREATE INDEX currently does not allow expressing all
> > > > that Ignite has in this field - say, I can't specify FULLTEXT index
> > > > types. (But, for clarity, I should also note that I don't see
> anything
> > > > else missing right away).
> > > >
> > > > On the other hand, if we want to enhance indexes someday, H2 may not
> > > > be there to support our custom syntax.
> > > >
> > > > All in all, I believe that the moment for messing the custom syntax
> > > > will no doubt come, sooner or later, and we can't avoid it forever.
> So
> > > > all our attempts to avoid messing with it now just delay the moment
> > > > when we will simply have no choice and will have to come up with
> > > > something quick and dirty in a rush and hurry.
> > > >
> > > > Yes, Ignite mode for H2 probably could be a solution for parsing, but
> > > > we have to keep in mind that compatibility mode in H2 is more than
> > > > syntax. And H2 folks will not likely be happy with just bunch of
> > > > random syntax changes that are otherwise irrelevant to RDBMS and will
> > > > not be used by or implemented in H2 itself anyway.
> > > >
> > > > - Alex
> > > >
> > > > 2017-01-30 4:18 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> > > > > On Fri, Jan 27, 2017 at 8:51 PM, Alexander Paschenko <
> > > > > alexander.a.paschenko@gmail.com> wrote:
> > > > >
> > > > >> Guys,
> > > > >>
> > > > >> And what would you say if I suggested that we implement custom
> > grammar
> > > > >> support with ANTLR? It allows you to describe pretty much any
> > grammar
> > > > >> in a declarative way, generates lexer and parser and then allows
> to
> > > > >> easily process parsed commands by implementing few (generated)
> > > > >> interfaces. Yesterday I gave it a try and it's really simple.
> > > > >> Downsides are use of generated code itself (I'm pretty sure
> someone
> > is
> > > > >> strongly against it) and relative wordiness of resulting code
> > written
> > > > >> manually. But this approach will no doubt save time and allow any
> > > > >> extensions or changes in syntax in the future w/o worrying about
> H2
> > or
> > > > >> anyone 3rd party. Thoughts?
> > > > >>
> > > > >>
> > > > > Alex,
> > > > >
> > > > > My preference would be to keep it simple, without introducing any
> > > custom
> > > > > grammar, at least for the "CREATE INDEX" command. I understand the
> > need
> > > > for
> > > > > decoupling cache from schema, but it will take much longer to
> > > implement,
> > > > > and I would leave it for phase 2. In phase 1 we can focus on
> > delivering
> > > > > this much needed feature to the community as soon as possible.
> > > > >
> > > > > Do you agree?
> > > > >
> > > > >
> > > > >> - Alex
> > > > >>
> > > > >> 2017-01-27 21:56 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com
> >:
> > > > >> > My point was that we can avoid dependency on 3rd party
> developers
> > > for
> > > > >> this
> > > > >> > relatively simple logic.
> > > > >> >
> > > > >> > On Fri, Jan 27, 2017 at 8:07 PM, Dmitriy Setrakyan <
> > > > >> dsetrakyan@apache.org>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin <
> > > > >> sergi.vladykin@gmail.com>
> > > > >> >> wrote:
> > > > >> >>
> > > > >> >> > H2 to some extent supports syntax (and quirks) from other
> > > > databases.
> > > > >> For
> > > > >> >> > example you can start it with MODE=MySQL and it will allow
> some
> > > > MySQL
> > > > >> >> > specific syntax to be handled.
> > > > >> >> >
> > > > >> >> > Having said that, IMO the most correct way to handle
> > non-standard
> > > > >> syntax
> > > > >> >> is
> > > > >> >> > to introduce H2 MODE=ApacheIgnite and put the needed switches
> > > > there.
> > > > >> >> >
> > > > >> >> > Though this needs to be negotiated with H2 folks.
> > > > >> >> >
> > > > >> >>
> > > > >> >> Sergi, can you ask the H2 folks about this? I agree, this
> sounds
> > > like
> > > > >> the
> > > > >> >> most correct way.
> > > > >> >>
> > > > >>
> > > >
> > >
> >
>
Re: Do not use H2 parser for DDL
Posted by Sergi Vladykin <se...@gmail.com>.
Nope, but we can add this to H2 to make it compatible with Oracle [1]
and/or PostgreSQL [2].
[1]
https://logicalread.com/oracle-11g-named-parameters-in-sql-function-calls-mc02
[2] https://www.postgresql.org/docs/9.1/static/sql-syntax-calling-funcs.html
Sergi
2017-02-03 17:41 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> Sergi,
>
> Does H2 support naming for function parameters? E.g. NEW_CACHE(backups: 1,
> mode: PARTITIONED)
>
> On Fri, Feb 3, 2017 at 4:28 PM, Sergi Vladykin <se...@gmail.com>
> wrote:
>
> > Actually we do not support FULLTEXT indexes in SQL right now. Thus I
> think
> > we will have to postpone this feature anyways.
> >
> > I hope that H2 Mode will solve most of the problems here. But another
> thing
> > is that IMO we should avoid inventing any "too custom" SQL syntax. For
> > example I agree that we have to be able to create caches from SQL, but I
> > don't like the idea of inventing CREATE CACHE syntax. May be its better
> to
> > have functions like the following:
> >
> > CALL NEW_CACHE(...);
> >
> > This is very straightforward and will allow us to avoid any problems with
> > syntax parsing.
> >
> > Sergi
> >
> > 2017-01-30 12:47 GMT+03:00 Alexander Paschenko <
> > alexander.a.paschenko@gmail.com>:
> >
> > > Dima,
> > >
> > > H2's grammar for CREATE INDEX currently does not allow expressing all
> > > that Ignite has in this field - say, I can't specify FULLTEXT index
> > > types. (But, for clarity, I should also note that I don't see anything
> > > else missing right away).
> > >
> > > On the other hand, if we want to enhance indexes someday, H2 may not
> > > be there to support our custom syntax.
> > >
> > > All in all, I believe that the moment for messing the custom syntax
> > > will no doubt come, sooner or later, and we can't avoid it forever. So
> > > all our attempts to avoid messing with it now just delay the moment
> > > when we will simply have no choice and will have to come up with
> > > something quick and dirty in a rush and hurry.
> > >
> > > Yes, Ignite mode for H2 probably could be a solution for parsing, but
> > > we have to keep in mind that compatibility mode in H2 is more than
> > > syntax. And H2 folks will not likely be happy with just bunch of
> > > random syntax changes that are otherwise irrelevant to RDBMS and will
> > > not be used by or implemented in H2 itself anyway.
> > >
> > > - Alex
> > >
> > > 2017-01-30 4:18 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> > > > On Fri, Jan 27, 2017 at 8:51 PM, Alexander Paschenko <
> > > > alexander.a.paschenko@gmail.com> wrote:
> > > >
> > > >> Guys,
> > > >>
> > > >> And what would you say if I suggested that we implement custom
> grammar
> > > >> support with ANTLR? It allows you to describe pretty much any
> grammar
> > > >> in a declarative way, generates lexer and parser and then allows to
> > > >> easily process parsed commands by implementing few (generated)
> > > >> interfaces. Yesterday I gave it a try and it's really simple.
> > > >> Downsides are use of generated code itself (I'm pretty sure someone
> is
> > > >> strongly against it) and relative wordiness of resulting code
> written
> > > >> manually. But this approach will no doubt save time and allow any
> > > >> extensions or changes in syntax in the future w/o worrying about H2
> or
> > > >> anyone 3rd party. Thoughts?
> > > >>
> > > >>
> > > > Alex,
> > > >
> > > > My preference would be to keep it simple, without introducing any
> > custom
> > > > grammar, at least for the "CREATE INDEX" command. I understand the
> need
> > > for
> > > > decoupling cache from schema, but it will take much longer to
> > implement,
> > > > and I would leave it for phase 2. In phase 1 we can focus on
> delivering
> > > > this much needed feature to the community as soon as possible.
> > > >
> > > > Do you agree?
> > > >
> > > >
> > > >> - Alex
> > > >>
> > > >> 2017-01-27 21:56 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> > > >> > My point was that we can avoid dependency on 3rd party developers
> > for
> > > >> this
> > > >> > relatively simple logic.
> > > >> >
> > > >> > On Fri, Jan 27, 2017 at 8:07 PM, Dmitriy Setrakyan <
> > > >> dsetrakyan@apache.org>
> > > >> > wrote:
> > > >> >
> > > >> >> On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin <
> > > >> sergi.vladykin@gmail.com>
> > > >> >> wrote:
> > > >> >>
> > > >> >> > H2 to some extent supports syntax (and quirks) from other
> > > databases.
> > > >> For
> > > >> >> > example you can start it with MODE=MySQL and it will allow some
> > > MySQL
> > > >> >> > specific syntax to be handled.
> > > >> >> >
> > > >> >> > Having said that, IMO the most correct way to handle
> non-standard
> > > >> syntax
> > > >> >> is
> > > >> >> > to introduce H2 MODE=ApacheIgnite and put the needed switches
> > > there.
> > > >> >> >
> > > >> >> > Though this needs to be negotiated with H2 folks.
> > > >> >> >
> > > >> >>
> > > >> >> Sergi, can you ask the H2 folks about this? I agree, this sounds
> > like
> > > >> the
> > > >> >> most correct way.
> > > >> >>
> > > >>
> > >
> >
>
Re: Do not use H2 parser for DDL
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Sergi,
Does H2 support naming for function parameters? E.g. NEW_CACHE(backups: 1,
mode: PARTITIONED)
On Fri, Feb 3, 2017 at 4:28 PM, Sergi Vladykin <se...@gmail.com>
wrote:
> Actually we do not support FULLTEXT indexes in SQL right now. Thus I think
> we will have to postpone this feature anyways.
>
> I hope that H2 Mode will solve most of the problems here. But another thing
> is that IMO we should avoid inventing any "too custom" SQL syntax. For
> example I agree that we have to be able to create caches from SQL, but I
> don't like the idea of inventing CREATE CACHE syntax. May be its better to
> have functions like the following:
>
> CALL NEW_CACHE(...);
>
> This is very straightforward and will allow us to avoid any problems with
> syntax parsing.
>
> Sergi
>
> 2017-01-30 12:47 GMT+03:00 Alexander Paschenko <
> alexander.a.paschenko@gmail.com>:
>
> > Dima,
> >
> > H2's grammar for CREATE INDEX currently does not allow expressing all
> > that Ignite has in this field - say, I can't specify FULLTEXT index
> > types. (But, for clarity, I should also note that I don't see anything
> > else missing right away).
> >
> > On the other hand, if we want to enhance indexes someday, H2 may not
> > be there to support our custom syntax.
> >
> > All in all, I believe that the moment for messing the custom syntax
> > will no doubt come, sooner or later, and we can't avoid it forever. So
> > all our attempts to avoid messing with it now just delay the moment
> > when we will simply have no choice and will have to come up with
> > something quick and dirty in a rush and hurry.
> >
> > Yes, Ignite mode for H2 probably could be a solution for parsing, but
> > we have to keep in mind that compatibility mode in H2 is more than
> > syntax. And H2 folks will not likely be happy with just bunch of
> > random syntax changes that are otherwise irrelevant to RDBMS and will
> > not be used by or implemented in H2 itself anyway.
> >
> > - Alex
> >
> > 2017-01-30 4:18 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> > > On Fri, Jan 27, 2017 at 8:51 PM, Alexander Paschenko <
> > > alexander.a.paschenko@gmail.com> wrote:
> > >
> > >> Guys,
> > >>
> > >> And what would you say if I suggested that we implement custom grammar
> > >> support with ANTLR? It allows you to describe pretty much any grammar
> > >> in a declarative way, generates lexer and parser and then allows to
> > >> easily process parsed commands by implementing few (generated)
> > >> interfaces. Yesterday I gave it a try and it's really simple.
> > >> Downsides are use of generated code itself (I'm pretty sure someone is
> > >> strongly against it) and relative wordiness of resulting code written
> > >> manually. But this approach will no doubt save time and allow any
> > >> extensions or changes in syntax in the future w/o worrying about H2 or
> > >> anyone 3rd party. Thoughts?
> > >>
> > >>
> > > Alex,
> > >
> > > My preference would be to keep it simple, without introducing any
> custom
> > > grammar, at least for the "CREATE INDEX" command. I understand the need
> > for
> > > decoupling cache from schema, but it will take much longer to
> implement,
> > > and I would leave it for phase 2. In phase 1 we can focus on delivering
> > > this much needed feature to the community as soon as possible.
> > >
> > > Do you agree?
> > >
> > >
> > >> - Alex
> > >>
> > >> 2017-01-27 21:56 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> > >> > My point was that we can avoid dependency on 3rd party developers
> for
> > >> this
> > >> > relatively simple logic.
> > >> >
> > >> > On Fri, Jan 27, 2017 at 8:07 PM, Dmitriy Setrakyan <
> > >> dsetrakyan@apache.org>
> > >> > wrote:
> > >> >
> > >> >> On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin <
> > >> sergi.vladykin@gmail.com>
> > >> >> wrote:
> > >> >>
> > >> >> > H2 to some extent supports syntax (and quirks) from other
> > databases.
> > >> For
> > >> >> > example you can start it with MODE=MySQL and it will allow some
> > MySQL
> > >> >> > specific syntax to be handled.
> > >> >> >
> > >> >> > Having said that, IMO the most correct way to handle non-standard
> > >> syntax
> > >> >> is
> > >> >> > to introduce H2 MODE=ApacheIgnite and put the needed switches
> > there.
> > >> >> >
> > >> >> > Though this needs to be negotiated with H2 folks.
> > >> >> >
> > >> >>
> > >> >> Sergi, can you ask the H2 folks about this? I agree, this sounds
> like
> > >> the
> > >> >> most correct way.
> > >> >>
> > >>
> >
>
Re: Do not use H2 parser for DDL
Posted by Sergi Vladykin <se...@gmail.com>.
Actually we do not support FULLTEXT indexes in SQL right now. Thus I think
we will have to postpone this feature anyways.
I hope that H2 Mode will solve most of the problems here. But another thing
is that IMO we should avoid inventing any "too custom" SQL syntax. For
example I agree that we have to be able to create caches from SQL, but I
don't like the idea of inventing CREATE CACHE syntax. May be its better to
have functions like the following:
CALL NEW_CACHE(...);
This is very straightforward and will allow us to avoid any problems with
syntax parsing.
Sergi
2017-01-30 12:47 GMT+03:00 Alexander Paschenko <
alexander.a.paschenko@gmail.com>:
> Dima,
>
> H2's grammar for CREATE INDEX currently does not allow expressing all
> that Ignite has in this field - say, I can't specify FULLTEXT index
> types. (But, for clarity, I should also note that I don't see anything
> else missing right away).
>
> On the other hand, if we want to enhance indexes someday, H2 may not
> be there to support our custom syntax.
>
> All in all, I believe that the moment for messing the custom syntax
> will no doubt come, sooner or later, and we can't avoid it forever. So
> all our attempts to avoid messing with it now just delay the moment
> when we will simply have no choice and will have to come up with
> something quick and dirty in a rush and hurry.
>
> Yes, Ignite mode for H2 probably could be a solution for parsing, but
> we have to keep in mind that compatibility mode in H2 is more than
> syntax. And H2 folks will not likely be happy with just bunch of
> random syntax changes that are otherwise irrelevant to RDBMS and will
> not be used by or implemented in H2 itself anyway.
>
> - Alex
>
> 2017-01-30 4:18 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> > On Fri, Jan 27, 2017 at 8:51 PM, Alexander Paschenko <
> > alexander.a.paschenko@gmail.com> wrote:
> >
> >> Guys,
> >>
> >> And what would you say if I suggested that we implement custom grammar
> >> support with ANTLR? It allows you to describe pretty much any grammar
> >> in a declarative way, generates lexer and parser and then allows to
> >> easily process parsed commands by implementing few (generated)
> >> interfaces. Yesterday I gave it a try and it's really simple.
> >> Downsides are use of generated code itself (I'm pretty sure someone is
> >> strongly against it) and relative wordiness of resulting code written
> >> manually. But this approach will no doubt save time and allow any
> >> extensions or changes in syntax in the future w/o worrying about H2 or
> >> anyone 3rd party. Thoughts?
> >>
> >>
> > Alex,
> >
> > My preference would be to keep it simple, without introducing any custom
> > grammar, at least for the "CREATE INDEX" command. I understand the need
> for
> > decoupling cache from schema, but it will take much longer to implement,
> > and I would leave it for phase 2. In phase 1 we can focus on delivering
> > this much needed feature to the community as soon as possible.
> >
> > Do you agree?
> >
> >
> >> - Alex
> >>
> >> 2017-01-27 21:56 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> >> > My point was that we can avoid dependency on 3rd party developers for
> >> this
> >> > relatively simple logic.
> >> >
> >> > On Fri, Jan 27, 2017 at 8:07 PM, Dmitriy Setrakyan <
> >> dsetrakyan@apache.org>
> >> > wrote:
> >> >
> >> >> On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin <
> >> sergi.vladykin@gmail.com>
> >> >> wrote:
> >> >>
> >> >> > H2 to some extent supports syntax (and quirks) from other
> databases.
> >> For
> >> >> > example you can start it with MODE=MySQL and it will allow some
> MySQL
> >> >> > specific syntax to be handled.
> >> >> >
> >> >> > Having said that, IMO the most correct way to handle non-standard
> >> syntax
> >> >> is
> >> >> > to introduce H2 MODE=ApacheIgnite and put the needed switches
> there.
> >> >> >
> >> >> > Though this needs to be negotiated with H2 folks.
> >> >> >
> >> >>
> >> >> Sergi, can you ask the H2 folks about this? I agree, this sounds like
> >> the
> >> >> most correct way.
> >> >>
> >>
>
Re: Do not use H2 parser for DDL
Posted by Alexander Paschenko <al...@gmail.com>.
Dima,
H2's grammar for CREATE INDEX currently does not allow expressing all
that Ignite has in this field - say, I can't specify FULLTEXT index
types. (But, for clarity, I should also note that I don't see anything
else missing right away).
On the other hand, if we want to enhance indexes someday, H2 may not
be there to support our custom syntax.
All in all, I believe that the moment for messing the custom syntax
will no doubt come, sooner or later, and we can't avoid it forever. So
all our attempts to avoid messing with it now just delay the moment
when we will simply have no choice and will have to come up with
something quick and dirty in a rush and hurry.
Yes, Ignite mode for H2 probably could be a solution for parsing, but
we have to keep in mind that compatibility mode in H2 is more than
syntax. And H2 folks will not likely be happy with just bunch of
random syntax changes that are otherwise irrelevant to RDBMS and will
not be used by or implemented in H2 itself anyway.
- Alex
2017-01-30 4:18 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> On Fri, Jan 27, 2017 at 8:51 PM, Alexander Paschenko <
> alexander.a.paschenko@gmail.com> wrote:
>
>> Guys,
>>
>> And what would you say if I suggested that we implement custom grammar
>> support with ANTLR? It allows you to describe pretty much any grammar
>> in a declarative way, generates lexer and parser and then allows to
>> easily process parsed commands by implementing few (generated)
>> interfaces. Yesterday I gave it a try and it's really simple.
>> Downsides are use of generated code itself (I'm pretty sure someone is
>> strongly against it) and relative wordiness of resulting code written
>> manually. But this approach will no doubt save time and allow any
>> extensions or changes in syntax in the future w/o worrying about H2 or
>> anyone 3rd party. Thoughts?
>>
>>
> Alex,
>
> My preference would be to keep it simple, without introducing any custom
> grammar, at least for the "CREATE INDEX" command. I understand the need for
> decoupling cache from schema, but it will take much longer to implement,
> and I would leave it for phase 2. In phase 1 we can focus on delivering
> this much needed feature to the community as soon as possible.
>
> Do you agree?
>
>
>> - Alex
>>
>> 2017-01-27 21:56 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
>> > My point was that we can avoid dependency on 3rd party developers for
>> this
>> > relatively simple logic.
>> >
>> > On Fri, Jan 27, 2017 at 8:07 PM, Dmitriy Setrakyan <
>> dsetrakyan@apache.org>
>> > wrote:
>> >
>> >> On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin <
>> sergi.vladykin@gmail.com>
>> >> wrote:
>> >>
>> >> > H2 to some extent supports syntax (and quirks) from other databases.
>> For
>> >> > example you can start it with MODE=MySQL and it will allow some MySQL
>> >> > specific syntax to be handled.
>> >> >
>> >> > Having said that, IMO the most correct way to handle non-standard
>> syntax
>> >> is
>> >> > to introduce H2 MODE=ApacheIgnite and put the needed switches there.
>> >> >
>> >> > Though this needs to be negotiated with H2 folks.
>> >> >
>> >>
>> >> Sergi, can you ask the H2 folks about this? I agree, this sounds like
>> the
>> >> most correct way.
>> >>
>>
Re: Do not use H2 parser for DDL
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Jan 27, 2017 at 8:51 PM, Alexander Paschenko <
alexander.a.paschenko@gmail.com> wrote:
> Guys,
>
> And what would you say if I suggested that we implement custom grammar
> support with ANTLR? It allows you to describe pretty much any grammar
> in a declarative way, generates lexer and parser and then allows to
> easily process parsed commands by implementing few (generated)
> interfaces. Yesterday I gave it a try and it's really simple.
> Downsides are use of generated code itself (I'm pretty sure someone is
> strongly against it) and relative wordiness of resulting code written
> manually. But this approach will no doubt save time and allow any
> extensions or changes in syntax in the future w/o worrying about H2 or
> anyone 3rd party. Thoughts?
>
>
Alex,
My preference would be to keep it simple, without introducing any custom
grammar, at least for the "CREATE INDEX" command. I understand the need for
decoupling cache from schema, but it will take much longer to implement,
and I would leave it for phase 2. In phase 1 we can focus on delivering
this much needed feature to the community as soon as possible.
Do you agree?
> - Alex
>
> 2017-01-27 21:56 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> > My point was that we can avoid dependency on 3rd party developers for
> this
> > relatively simple logic.
> >
> > On Fri, Jan 27, 2017 at 8:07 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > wrote:
> >
> >> On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin <
> sergi.vladykin@gmail.com>
> >> wrote:
> >>
> >> > H2 to some extent supports syntax (and quirks) from other databases.
> For
> >> > example you can start it with MODE=MySQL and it will allow some MySQL
> >> > specific syntax to be handled.
> >> >
> >> > Having said that, IMO the most correct way to handle non-standard
> syntax
> >> is
> >> > to introduce H2 MODE=ApacheIgnite and put the needed switches there.
> >> >
> >> > Though this needs to be negotiated with H2 folks.
> >> >
> >>
> >> Sergi, can you ask the H2 folks about this? I agree, this sounds like
> the
> >> most correct way.
> >>
>
Re: Do not use H2 parser for DDL
Posted by Alexander Paschenko <al...@gmail.com>.
Guys,
And what would you say if I suggested that we implement custom grammar
support with ANTLR? It allows you to describe pretty much any grammar
in a declarative way, generates lexer and parser and then allows to
easily process parsed commands by implementing few (generated)
interfaces. Yesterday I gave it a try and it's really simple.
Downsides are use of generated code itself (I'm pretty sure someone is
strongly against it) and relative wordiness of resulting code written
manually. But this approach will no doubt save time and allow any
extensions or changes in syntax in the future w/o worrying about H2 or
anyone 3rd party. Thoughts?
- Alex
2017-01-27 21:56 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> My point was that we can avoid dependency on 3rd party developers for this
> relatively simple logic.
>
> On Fri, Jan 27, 2017 at 8:07 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
>> On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin <se...@gmail.com>
>> wrote:
>>
>> > H2 to some extent supports syntax (and quirks) from other databases. For
>> > example you can start it with MODE=MySQL and it will allow some MySQL
>> > specific syntax to be handled.
>> >
>> > Having said that, IMO the most correct way to handle non-standard syntax
>> is
>> > to introduce H2 MODE=ApacheIgnite and put the needed switches there.
>> >
>> > Though this needs to be negotiated with H2 folks.
>> >
>>
>> Sergi, can you ask the H2 folks about this? I agree, this sounds like the
>> most correct way.
>>
Re: Do not use H2 parser for DDL
Posted by Vladimir Ozerov <vo...@gridgain.com>.
My point was that we can avoid dependency on 3rd party developers for this
relatively simple logic.
On Fri, Jan 27, 2017 at 8:07 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin <se...@gmail.com>
> wrote:
>
> > H2 to some extent supports syntax (and quirks) from other databases. For
> > example you can start it with MODE=MySQL and it will allow some MySQL
> > specific syntax to be handled.
> >
> > Having said that, IMO the most correct way to handle non-standard syntax
> is
> > to introduce H2 MODE=ApacheIgnite and put the needed switches there.
> >
> > Though this needs to be negotiated with H2 folks.
> >
>
> Sergi, can you ask the H2 folks about this? I agree, this sounds like the
> most correct way.
>
Re: Do not use H2 parser for DDL
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Jan 27, 2017 at 5:45 AM, Sergi Vladykin <se...@gmail.com>
wrote:
> H2 to some extent supports syntax (and quirks) from other databases. For
> example you can start it with MODE=MySQL and it will allow some MySQL
> specific syntax to be handled.
>
> Having said that, IMO the most correct way to handle non-standard syntax is
> to introduce H2 MODE=ApacheIgnite and put the needed switches there.
>
> Though this needs to be negotiated with H2 folks.
>
Sergi, can you ask the H2 folks about this? I agree, this sounds like the
most correct way.
Re: Do not use H2 parser for DDL
Posted by Sergi Vladykin <se...@gmail.com>.
H2 to some extent supports syntax (and quirks) from other databases. For
example you can start it with MODE=MySQL and it will allow some MySQL
specific syntax to be handled.
Having said that, IMO the most correct way to handle non-standard syntax is
to introduce H2 MODE=ApacheIgnite and put the needed switches there.
Though this needs to be negotiated with H2 folks.
Sergi
2017-01-27 15:15 GMT+03:00 Alexey Kuznetsov <ak...@apache.org>:
> We should care about statements like this:
> /* bla-bla */ CREATE TABLE
>
> So naive "startsWith(...)" will not work in some scenarios.
>
> :)
>
> On Fri, Jan 27, 2017 at 7:06 PM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
>
> > Folks,
> >
> > H2 has nice and powerful SQL parser, and we pass all incoming SQL
> commands
> > through it. However it doesn't support custom SQL syntax, which we are
> > likely to need in DDL at some point in future.
> >
> > As DDL statements are relatively easy to parse comparing to SELECTs and
> > they do not involve optimizer, we can easily create object model of DDL
> > command without invoking H2 at all.
> >
> > I propose to introduce small change into our parsing logic as follows:
> >
> > if (req.startsWith("CREATE" or "ALTER" or "DELETE")
> > parseDdlManually(req);
> > else
> > parseWithH2(req);
> >
> > It should be enough to support any custom syntax for our DDL with any
> > limitations and without any dependencies on H2 folks.
> >
> > For instance, see H2 "CREATE TABLE" [1] and "CREATE INDEX" [2] structure.
> > It is already very simple. But provided that Ignite doesn't support most
> of
> > H2 DDL features, Ignite DDL structure will be even simpler.
> >
> > it should take no more than 1-2 days to implement fully-fledged parsing
> for
> > these two commands.
> >
> > Thoughts?
> >
> > Vladimir.
> >
> > [1] http://www.h2database.com/html/grammar.html#create_table
> > [2] http://www.h2database.com/html/grammar.html#create_index
> >
>
>
>
> --
> Alexey Kuznetsov
>
Re: Do not use H2 parser for DDL
Posted by Alexey Kuznetsov <ak...@apache.org>.
We should care about statements like this:
/* bla-bla */ CREATE TABLE
So naive "startsWith(...)" will not work in some scenarios.
:)
On Fri, Jan 27, 2017 at 7:06 PM, Vladimir Ozerov <vo...@gridgain.com>
wrote:
> Folks,
>
> H2 has nice and powerful SQL parser, and we pass all incoming SQL commands
> through it. However it doesn't support custom SQL syntax, which we are
> likely to need in DDL at some point in future.
>
> As DDL statements are relatively easy to parse comparing to SELECTs and
> they do not involve optimizer, we can easily create object model of DDL
> command without invoking H2 at all.
>
> I propose to introduce small change into our parsing logic as follows:
>
> if (req.startsWith("CREATE" or "ALTER" or "DELETE")
> parseDdlManually(req);
> else
> parseWithH2(req);
>
> It should be enough to support any custom syntax for our DDL with any
> limitations and without any dependencies on H2 folks.
>
> For instance, see H2 "CREATE TABLE" [1] and "CREATE INDEX" [2] structure.
> It is already very simple. But provided that Ignite doesn't support most of
> H2 DDL features, Ignite DDL structure will be even simpler.
>
> it should take no more than 1-2 days to implement fully-fledged parsing for
> these two commands.
>
> Thoughts?
>
> Vladimir.
>
> [1] http://www.h2database.com/html/grammar.html#create_table
> [2] http://www.h2database.com/html/grammar.html#create_index
>
--
Alexey Kuznetsov