Re: splitting CQL parser & spec into separate repo

2017-03-21 Thread Anthony Grasso
This is a great idea

+1 (non-binding)

On 22 March 2017 at 07:04, Edward Capriolo  wrote:

> On Tue, Mar 21, 2017 at 3:24 PM, Mark Dewey  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 
> > 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.
>


Re: splitting CQL parser & spec into separate repo

2017-03-21 Thread Edward Capriolo
On Tue, Mar 21, 2017 at 3:24 PM, Mark Dewey  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 
> 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.


Re: splitting CQL parser & spec into separate repo

2017-03-21 Thread Mark Dewey
I can immediately think of a project I would use that in. +1

On Tue, Mar 21, 2017 at 12:18 PM Jonathan Haddad  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
>


splitting CQL parser & spec into separate repo

2017-03-21 Thread Jonathan Haddad
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


[GitHub] cassandra pull request #:

2017-03-21 Thread Baddaboo
Github user Baddaboo commented on the pull request:


https://github.com/apache/cassandra/commit/5b8b1ce26cd073a44ddf7c7a6750da409a343eba#commitcomment-21412404
  
Maybe @belliottsmith was just writing this printout in 
[Italian](https://translate.google.com/#eo/en/datata), referring to a 
Tinder-like dating server 😃 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---