This is a great idea +1 (non-binding)
On 22 March 2017 at 07:04, Edward Capriolo <edlinuxg...@gmail.com> wrote: > 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. >
