No, it will work as follows:
Model parse(String sql) {
Model res = tryParseWithIgnite(sql); // Parse what we can
if (res == null)
res = parseWithH2(sql);
return res;
}
We will need a number of custom commands which are not present in H2.
On Wed, Aug 2, 2017 at 3:44 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:
> On Tue, Aug 1, 2017 at 11:08 PM, Vladimir Ozerov <voze...@gridgain.com>
> wrote:
>
> > Own parser capable of processing non-SELECT and non-DML statements.
> >
>
> And how will it integrate with H2 parser? Or are you suggesting that we get
> rid of H2 SQL parser?
>
>
> >
> > On Tue, Aug 1, 2017 at 9:44 PM, <dsetrak...@apache.org> wrote:
> >
> > > Vova, I am not sure what you are proposing... extending H2 parser with
> > new
> > > syntax or a brand new parser?
> > >
> > > D.
> > >
> > > On Aug 1, 2017, 4:26 PM, at 4:26 PM, Vladimir Ozerov <
> > voze...@gridgain.com>
> > > wrote:
> > > >Andrey,
> > > >
> > > >Note that I am not proposing to remove H2 as a whole. Main point for
> > > >now is
> > > >to support missing pieces of DDL syntax and possibly and some
> > > >extensions.
> > > >Several examples:
> > > >
> > > >1) Currently CREATE TABLE command looks ugly:
> > > >CREATE TABLE Person (id LONG, name VARCHAR) WITH
> "template=PARTITIONED,
> > > >backups=1, ..."
> > > >
> > > >Commas typically treated in a special way in editors and IDEs, so user
> > > >will
> > > >have to escape them, making usability even worse.
> > > >
> > > >2) What if I need to introduce new template? Currently you have to
> > > >restart
> > > >the node with new config. With our own parser you will do:
> > > >CREATE TEMPLATE my_template MODE=PARTITIONED, BACKUPS=1;
> > > >CREATE TABLE Person (...) TEMPLATE my_template;
> > > >
> > > >No restarts, everything is done dynamically.
> > > >
> > > >
> > > >
> > > >On Tue, Aug 1, 2017 at 4:18 PM, Andrey Mashenkov
> > > ><andrey.mashen...@gmail.com
> > > >> wrote:
> > > >
> > > >> Vovan,
> > > >>
> > > >> 1. What about ANSI-xx compliant? Will new syntax brake it in some
> > > >cases or
> > > >> just extend?
> > > >>
> > > >> 2. This would be great to have more ways for optimization.
> > > >>
> > > >> Does anyone know or may be have experience with some frameworks or
> > > >open
> > > >> projects which can be helpful? E.g. Apache Calcite?
> > > >>
> > > >> On Tue, Aug 1, 2017 at 3:25 PM, Vladimir Ozerov
> > > ><voze...@gridgain.com>
> > > >> wrote:
> > > >>
> > > >> > Igniters,
> > > >> >
> > > >> > As you know, we rely on H2 for SQL query parsing. This has several
> > > >> > drawbacks:
> > > >> >
> > > >> > 1) Limited and ugly syntax
> > > >> > Ignite has lot's of unique concepts which are in no way supported
> > > >by
> > > >> > traditional RDBMS in general, or by H2 in particular. For example:
> > > >> > - query hints ("distributedJoins", "replicatedOnly", "colocated")
> > > >> > - index hints ("inline size")
> > > >> > - cache configuration (memory policy, affinity key, cache mode,
> > > >etc)
> > > >> > - transaction mode (concurrency, isolation, timeouts) - not needed
> > > >now,
> > > >> but
> > > >> > will be required when transactional SQL is ready
> > > >> >
> > > >> > 2) Performance implications
> > > >> > Typical SQL processing flow looks as follows
> > > >> > - Parse String to H2 object form (prepared statement)
> > > >> > - Convert it to Ignite object form (AST)
> > > >> > - Then convert it back to map and reduce queries in String form
> > > >> > - Convert map and reduce queries from String back to H2
> > > >PreparedStatement
> > > >> > again for final execution
> > > >> >
> > > >> > This is way too much. Moreover, H2 optimizes query during parsing,
> > > >but
> > > >> it's
> > > >> > optimizer is not smart enough. E.g., Ignite "IN" clauses are not
> > > >> optimized
> > > >> > and hence doesn't use indexes, so we force users to use
> > > >intermediate
> > > >> tables
> > > >> > with very ugly syntax, while we should do that on our own instead.
> > > >> Another
> > > >> > example is common expression elimination - H2 cannot do that even
> > > >for
> > > >> > deterministic functions, what cause performance problems
> > > >frequently.
> > > >> >
> > > >> > I propose to start some work in direction of our own parser. We
> can
> > > >start
> > > >> > with something very simple, e.g. DDL support, which is not that
> > > >complex,
> > > >> > but will improve usability significantly. And then gradually
> extend
> > > >it to
> > > >> > more complex statements where both rich BNF and optimizer is
> > > >necessary.
> > > >> >
> > > >> > Thoughts?
> > > >> >
> > > >> > Vladimir.
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Best regards,
> > > >> Andrey V. Mashenkov
> > > >>
> > >
> >
>
