I am -1. For a few reasons: Cassandra will be the only database ( that I know of ) where the only official client to the database will live in source control outside of the project. I would like some clarity on this development will go on in an open source fashion. Namely:
1) Who does and how do they do regression testing between the database server and the client? I.E. are the bugs "on the client" or "in the server" hard to say when there is no official client. 2) How can an open source apache project depend on a non apache managed resource to accomplish basic development? IE if there is a cassandra committer that does not have commit on the driver source code get work done? 3) Who has the "final word" on how a feature is implemented in the native protocol? Imagine there are two implementations of CQL native-cql-ruby and native-cql-java. Let's say these libraries have both interpreted the transport spec differently. One of them has to be broken to fix the problem. Who resolves this issue and how? "With static columns and LWT batch support [1] landing in 2.0.6, and UDT in 2.1 [2], I don't know of any use cases for Thrift that can't be done in CQL." Do we mean CQL the transport, CQL the storage engine, CQL the procedure engine (auto timestamps), or CQL the language? :) Its hard for thrift to "do things" when specific "read before write list collection operations" are impossible to do from a "transport". "To a large degree, this merely formalizes what is already de facto reality. Most thrift clients have not even added support for atomic_batch_mutate and cas from 2.0, and popular clients like Astyanax are migrating to the native protocol." This is such a loaded statement, most committers have not even "committed" to adding features to thrift. Take for example " https://issues.apache.org/jira/browse/CASSANDRA-5435"; adding range tombstones to thrift was actually a very simple effort. One day I just got off my couch and went through the simple effort of pushing this along. What is happening is a self fulfilling prophecy, if everyone throws tons of development effort in one direction unsurprisingly the other direction lags behind. On Tue, Mar 11, 2014 at 1:43 PM, Gary Dusbabek <gdusba...@gmail.com> wrote: > +1 > > > > On Tue, Mar 11, 2014 at 12:00 PM, Jonathan Ellis <jbel...@gmail.com> > wrote: > > > CQL3 is almost two years old now and has proved to be the better API > > that Cassandra needed. CQL drivers have caught up with and passed the > > Thrift ones in terms of features, performance, and usability. CQL is > > easier to learn and more productive than Thrift. > > > > With static columns and LWT batch support [1] landing in 2.0.6, and > > UDT in 2.1 [2], I don't know of any use cases for Thrift that can't be > > done in CQL. Contrawise, CQL makes many things easy that are > > difficult to impossible in Thrift. New development is overwhelmingly > > done using CQL. > > > > To date we have had an unofficial and poorly defined policy of "add > > support for new features to Thrift when that is 'easy.'" However, > > even relatively simple Thrift changes can create subtle complications > > for the rest of the server; for instance, allowing Thrift range > > tombtones would make filter conversion for CASSANDRA-6506 more > > difficult. > > > > Thus, I think it's time to officially close the book on Thrift. We > > will retain it for backwards compatibility, but we will commit to > > adding no new features or changes to the Thrift API after 2.1.0. This > > will help send an unambiguous message to users and eliminate any > > remaining confusion from supporting two APIs. If any new use cases > > come to light that can be done with Thrift but not CQL, we will commit > > to supporting those in CQL. > > > > (To a large degree, this merely formalizes what is already de facto > > reality. Most thrift clients have not even added support for > > atomic_batch_mutate and cas from 2.0, and popular clients like > > Astyanax are migrating to the native protocol.) > > > > Reasonable? > > > > [1] https://issues.apache.org/jira/browse/CASSANDRA-6561 > > [2] https://issues.apache.org/jira/browse/CASSANDRA-5590 > > > > -- > > Jonathan Ellis > > Project Chair, Apache Cassandra > > co-founder, http://www.datastax.com > > @spyced > > >
