On Tue, Mar 21, 2017 at 5:45 PM, Anthony Grasso <anthony.gra...@gmail.com> wrote:
> 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. > > > I believe you could accomplish a similar goal by making a multi-module project https://maven.apache.org/guides/mini/guide-multiple-modules.html. Probably not as easy thanks to ant, but I think that is a better route. One there actually are N dependent projects in the wild you can make the case for overhead which is both technical and in ASF based.
