Re: splitting CQL parser & spec into separate repo
On Thu, Mar 23, 2017 at 10:56 AM, Eric Evans wrote: > On Wed, Mar 22, 2017 at 10:01 AM, Edward Capriolo > wrote: > > 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. > > This was my first thought: If we were using Maven, we'd probably > already have created this as a module[*]. > > > [*]: Maybe a surprise to some given how strongly I pushed back against > it in the Early Days, but we would be so much better off at this point > with Maven. > > > -- > Eric Evans > john.eric.ev...@gmail.com > Well the ant maven bit is a separate issue: It still could be done with ant, it could be done in a way that the port is very easy. http://ant.apache.org/easyant/history/trunk/ref/anttasks/SubModuletask.html
Re: splitting CQL parser & spec into separate repo
On Wed, Mar 22, 2017 at 10:01 AM, Edward Capriolo wrote: > 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. This was my first thought: If we were using Maven, we'd probably already have created this as a module[*]. [*]: Maybe a surprise to some given how strongly I pushed back against it in the Early Days, but we would be so much better off at this point with Maven. -- Eric Evans john.eric.ev...@gmail.com
Re: splitting CQL parser & spec into separate repo
On Tue, Mar 21, 2017 at 5:45 PM, Anthony Grasso wrote: > 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. > > > 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.
Re: splitting CQL parser & spec into separate repo
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
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
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
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