sorry for the confusion. I'm not trying to add relational features like constraints, etc.
what I want to do is make writing reports easier than the ugly mess that is today. Anyone that's used the various reporting tools for hadoop knows how ugly and painful it is. Without features like exist, or, like, group by, etc, writing simple reports is more painful than it needs to be. We can apply the principles of a standard structured query syntax without taking all the relational stuff. To me the query language is independent of the underlying database. On Tue, Mar 11, 2014 at 9:50 PM, Steven A Robenalt <srobe...@stanford.edu>wrote: > Okay, I'm officially lost on this thread. If you plan on forking Cassandra > to preserve and continue to enhance the Thrift interface, you would also > want to add a bunch of relational features to CQL as part of that same fork? > > > On Tue, Mar 11, 2014 at 6:20 PM, Edward Capriolo <edlinuxg...@gmail.com>wrote: > >> "one of the things I'd like to see happen is for Cassandra to support >> queries with disjunction, exist, subqueries, joins and like. In theory CQL >> could support these features in the future. Cassandra would need a new >> query compiler and query planner. I don't see how the current design could >> do these things without a significant redesign/enhancement. In a past life, >> I implemented an inference rule engine, so I've spent over decade studying >> and implementing query optimizers. All of these things can be done, it's >> just a matter of people finding the time to do it." >> >> I see what your saying. CQL started as a way to make slice easier but it >> is not even a query language, retrofitting these things is going to be very >> hard. >> >> >> >> On Tue, Mar 11, 2014 at 7:45 PM, Peter Lin <wool...@gmail.com> wrote: >> >>> >>> I have no problems maintain my own fork :) or joining others forking >>> cassandra. >>> >>> I'd be happy to work with you or anyone else to add features to thrift. >>> That's the great thing about open source. Each person can scratch a >>> technical itch and do what they love. I see lots of potential for Cassandra >>> and many of them include improving thrift to make it happen. Some of the >>> features in theory "could" be done in CQL, but not with the current design. >>> >>> one of the things I'd like to see happen is for Cassandra to support >>> queries with disjunction, exist, subqueries, joins and like. In theory CQL >>> could support these features in the future. Cassandra would need a new >>> query compiler and query planner. I don't see how the current design could >>> do these things without a significant redesign/enhancement. In a past life, >>> I implemented an inference rule engine, so I've spent over decade studying >>> and implementing query optimizers. All of these things can be done, it's >>> just a matter of people finding the time to do it. >>> >>> >>> >>> >>> On Tue, Mar 11, 2014 at 6:17 PM, Edward Capriolo >>> <edlinuxg...@gmail.com>wrote: >>> >>>> Peter, >>>> >>>> My advice. Do not bother. I have become very active recently in >>>> attempting to add features to thrift. I had 4 open tickets I was actively >>>> working on. (I even found two bugs in the Cassandra in the process). >>>> >>>> People were aware of this and still called this vote. Several commit >>>> people have voted in a +1 and my -1 vote is non binding. It is a clear >>>> message: The committers are unwilling to accept new thrift features even if >>>> said features are contributed by others. >>>> >>>> Edward >>>> >>>> >>>> >>>> On Tue, Mar 11, 2014 at 5:51 PM, Peter Lin <wool...@gmail.com> wrote: >>>> >>>>> >>>>> My bias opinion, just because some member of cassandra develop want to >>>>> abandon Thrift, I see benefits of continuing to improve it. >>>>> >>>>> The great thing about open source is that as long as some people want >>>>> to keep working on it and improve it, it can happen. I plan to do my best >>>>> to keep Thrift going, since it gives me fine grain control that I want and >>>>> need. If the ultimate goal of Cassandra is to be "as close to SQL" as >>>>> practical, my bias take is use a NewSQL database that gives you the full >>>>> power of subqueries, like, exists and disjunction. >>>>> >>>>> When customers ask me which database to choose and they really want >>>>> Relational model, I tell them use NewSql. I love that Cassandra sits >>>>> between NoSql and NewSql. There are things I do in Cassandra today that >>>>> are >>>>> much harder in NewSql or NoSql document databases. NewSql database can >>>>> scale to similar sizes, so the "big" part of big data won't be a >>>>> significant advantage forever. Looking at some of the recent NewSql >>>>> performance numbers, it's clear the gap is closing. >>>>> >>>>> peter >>>>> >>>>> >>>>> >>>>> On Tue, Mar 11, 2014 at 3:59 PM, Tyler Hobbs <ty...@datastax.com>wrote: >>>>> >>>>>> >>>>>> On Tue, Mar 11, 2014 at 2:41 PM, Shao-Chuan Wang < >>>>>> shaochuan.w...@bloomreach.com> wrote: >>>>>> >>>>>>> >>>>>>> So, does anyone know how to do "describing the splits" and >>>>>>> "describing the local rings" using native protocol? >>>>>>> >>>>>> >>>>>> For a ring description, you would do something like "select peer, >>>>>> tokens from system.peers". I'm not sure about describe_splits(). >>>>>> >>>>>> >>>>>>> >>>>>>> Also, cqlsh uses python client, which is talking via thrift protocol >>>>>>> too. Does it mean that it will be migrated to native protocol soon as >>>>>>> well? >>>>>>> >>>>>> >>>>>> Yes: https://issues.apache.org/jira/browse/CASSANDRA-6307 >>>>>> >>>>>> >>>>>> -- >>>>>> Tyler Hobbs >>>>>> DataStax <http://datastax.com/> >>>>>> >>>>> >>>>> >>>> >>> >> > > > -- > Steve Robenalt > Software Architect > HighWire | Stanford University > 425 Broadway St, Redwood City, CA 94063 > > srobe...@stanford.edu > http://highwire.stanford.edu > > > > > >
