I'd like to point out that we already do have Ignite mode in H2 parser
(thanks Sergi) and thus have AFFINITY keyword support. Is is suggested
that we should abandon H2 way at all? Or should we suggest adding to
H2 only rather minor stuff (like some keywords for existing commands)
whilst introducing completely new commands for our own parser?
- Alex
2017-08-02 9:01 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>:
> 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
>> > > >>
>> > >
>> >
>>
