Dima, Manual parsing is too hard to implement. More precisely - too time consuming. ANTLR will let us add more and more grammar with minimal efforts.
Immediate benefits for the project: 1) Nice CREATE TABLE syntax 2) Ability to add any administrative commands we want. E.g. "CLUSTER ACTIVATE", "CREATE CACHE". Long-term benefits: 1) Nice syntax all over our SQL (e.g. we will be able to tune single SELECT with hints, instead of current ugly flags on SqlFieldsQuery) 2) Nice and consistent error messages 3) Full control on what we support and what we don't 4) Removing dependency on H2 Performance will be evaluated separately [1]. [1] https://issues.apache.org/jira/plugins/servlet/mobile#issue/IGNITE-6320 пт, 8 сент. 2017 г. в 21:01, Dmitriy Setrakyan <[email protected]>: > Vova, license-wise it is OK, but I do not like adding the dependency. Right > now we have H2 doing parsing for us. Why would ANTLR be better? What > happens when we potentially notice a performance issue or any other issue > in ANTLR under load? > > Can we try doing parsing ourselves instead of adding a dependency? > > D. > > On Fri, Sep 8, 2017 at 2:23 AM, Vladimir Ozerov <[email protected]> > wrote: > > > Igniters, > > > > We are evaluating ANTLR [1] as a parser generator for our SQL engine [2]. > > At first glance it looks very good, we already able to parse certain SQL > > commands with it. If implemented, it would greatly improve usability of > our > > SQL engine. However, it goes under BSD license and require one small > > runtime dependency "antlr-runtime" [3]. > > > > I need assistance form someone with greater experience with different > > licences - is it fine to add this dependency to Ignite? Would it violate > > ASF licensing rules? > > > > AFAIK other ASF projects use it, e.g. Hive [4]. > > > > Vladimir. > > > > [1] http://www.antlr.org/ > > [2] https://issues.apache.org/jira/browse/IGNITE-6276 > > [3] https://mvnrepository.com/artifact/org.antlr/antlr-runtime > > [4] https://github.com/apache/hive/blob/master/ql/pom.xml#L165 > > >
