I should add that I'm not trying to ignite a flame war. Just trying to understand your intentions.
On Tue, Mar 11, 2014 at 6: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 > > > > > > -- Steve Robenalt Software Architect HighWire | Stanford University 425 Broadway St, Redwood City, CA 94063 srobe...@stanford.edu http://highwire.stanford.edu
