On Tue, Mar 21, 2017 at 3:24 PM, Mark Dewey <milde...@gmail.com> wrote:
> I can immediately think of a project I would use that in. +1 > > On Tue, Mar 21, 2017 at 12:18 PM Jonathan Haddad <j...@jonhaddad.com> > wrote: > > > I created CASSANDRA-13284 a few days ago with the intent of starting a > > discussion around the topic of breaking the CQL parser out into a > separate > > project. I see a few benefits to doing it and was wondering what the > folks > > here thought as well. > > > > First off, the Java CQL parser would obviously continue to be the > reference > > parser. I'd love to see other languages have CQL parsers as well, but > the > > intent here isn't for the OSS C* team to be responsible for maintaining > > that. My vision here is simply the ability to have some high level > > CQLParser.parse(statement) call that returns the parse tree, nothing > more. > > > > It would be nice to be able to leverage that parser in other projects > such > > as IDEs, code gen tools, etc. It would be outstanding to be able to > create > > the parser tests in such a way that they can be referenced by other > parsers > > in other languages. Yay code reuse. It also has the benefit of making > the > > codebase a little more modular and a bit easier to understand. > > > > Thoughts? > > > > Jon > > > It turns out that a similar thing was done with Hive. https://calcite.apache.org/ https://calcite.apache.org/community/#apache-calcite-one-planner-fits-all The challenge is typically adoption. The elevator pitch is like: "EVERYONE WILL SHARE THIS AND IT WILL BE AWESOME". Maybe this is the wrong word, but lets just say frenemies exist and they do not like control of something moving to a shared medium. Technical issues like ANTLR 3 vs ANTRL 4 etc. For something like Hive the challenge is the parser/planner needs only be fast enough for analytic queries but that would not be the right move for say CQL.
