I agree with Edward here. We use Thrift too and we haven't really found a good enough reason to move to CQL3.
-- Drew On Dec 1, 2012, at 10:24 AM, Edward Capriolo <edlinuxg...@gmail.com> wrote: > I do not understand why everyone wants to force this issue on removing > thrift. If cql, cql sparse tables and the new transport are better people > will naturally begin to use them, but as it stands now I see the it > this way: > > Thrift still has more clients for more languages, thrift has more higher > level clients for more languages. > Thrift has Hadoop support hive support and pig support in the wild. > Thrift has third party tools like Orm tools, support for tools like flume. > > Most of cql3 features like collections do not work with compact tables, > and compact tables are much more space efficient then their cql3 sparse > counterparts, composite rows with UTf column names, blank rows, etc. > Cql3 binary client is only available for in beta stage for a few languages. > > So the project can easily remove thrift today but until a majority of the > tooling by the community adopts the transport and for the most part cqls > sparse tables it is not going to mean anything. Many people already have > code live in production working fine with the old toolset and will be > unwilling to convert something just because.... > > Think about it like this a company like mine that already has something in > production. Even if you could convince me us that cql native transport was > better, which by the way no one has showed me a vast performance reason to > this point, they still may not want to invest the resources to convert > their app. Many companies endured the painful transition from Cassandra 0.6 > to Cassandra 0.7 conversion and they are not eagerly going to entertain > another change which is mostly cosmetic. > > Also I find issues like this extremely frustrating. > https://issues.apache.org/jira/browse/CASSANDRA-4924 > > It seems like the project is drawing a hard line in the sand dividing > people. Is it the case that cql3's sparse tables can't be accessed > by thrift, or is it the case that no one wants to make this happen? Like is > it technically impossible? It seems not to me in Cassandra > Row key, column, and value are all still byte arrays right? So I do not see > why thrift users need to be locked out of them. Just like composites we > will figure out how to pack the bytes. > > I hope that we can stop talking about removing thrift until there is some > consensus between active users that it is not in use anymore. > This consensus is not as simple as n committers saying that something is > technically not needed anymore. It has to look at the users, the number of > clients, the number of languages, the number of high level tools available. > In the mean time when issues like 4924 pop up it would be better if people > tried to find solutions for maximum forward and backward compatibility > instead of drawing a line and trying to shut thrift users out of things. > > Avro was much the same way . I had a spirited debate on irc and got > basicallly insulted because i belived thrift was not dead. The glory of > avro never came true because it really did not work for clients outside a > few languages. Cql and the binary transport has to pass this same litmus > test. Let it gain momentum and have rock solid clients for 5 languages and > have higher level tools written on top of it then its easy to say thrift is > not needed anymore. > > > On Saturday, December 1, 2012, Sylvain Lebresne wrote: > >> I agree on 2.0. >> >> For the thrift part, we've said clearly that we wouldn't remove it any time >> soon so let's stick to that. Besides, I would agree it's too soon anyway. >> What we can do however in the relatively short term on that front, is to >> pull thrift in it's own jar (we've almost removed all internal dependencies >> on thrift, and the few remaining ones will be easy to kill) and make that >> jar optional if you don't want to use it. >> >> -- >> Sylvain >> >> >> On Sat, Dec 1, 2012 at 2:52 AM, Ray Slakinski >> <ray.slakin...@gmail.com<javascript:;> >>> wrote: >> >>> I agree, I don't think its a great idea to drop thrift until the back >>> end tools are 100% compatible and have some level of agreement from the >>> major users of >>> Cassandra. >>> >>> Paying off technical dept though I'm all for, and I think its key to the >>> long term success of the application. Right now Supercolumns to someone >>> new coming to the system might think "Hey, these things look great. Lets >>> use them" and in a few months time hate all things that are cassandra. >>> >>> Ray Slakinski >>> >>> On 12/01, Jonathan Ellis wrote: >>>> As attractive as it would be to clean house, I think we owe it to our >>>> users to keep Thrift around for the forseeable future rather than >>>> orphan all Thrift-using applications (which is virtually everyone) on >>>> 1.2. >>>> >>>> On Sat, Dec 1, 2012 at 7:33 AM, Jason Brown >>>> <jasedbr...@gmail.com<javascript:;> >>> >>> wrote: >>>>> Hi Jonathan, >>>>> >>>>> I'm in favor of paying off the technical debt, as well, and I wonder >> if >>>>> there is value in removing support for thrift with 2.0? We're >>> currently in >>>>> 'do as little as possible' mode with thrift, so should we >> aggressively >>> cast >>>>> it off and push the binary CQL protocol? Seems like a jump to '2.0', >>> along >>>>> with the other initiatives, would be a reasonable time/milestone to >> do >>> so. >>>>> >>>>> Thanks, >>>>> >>>>> -Jason >>>>> >>>>> >>>>> On Fri, Nov 30, 2012 at 12:12 PM, Jonathan Ellis >>>>> <jbel...@gmail.com<javascript:;> >>> >>> wrote: >>>>> >>>>>> The more I think about it, the more I think we should call 1.2-next, >>>>>> 2.0. I'd like to spend some time paying off our technical debt: >>>>>> >>>>>> - replace supercolumns with composites (CASSANDRA-3237) >>>>>> - rewrite counters (CASSANDRA-4775) >>>>>> - improve storage engine support for wide rows >>>>>> - better stage management to improve latency (disruptor? lightweight >>>>>> threads? custom executor + queue?) >>>>>> - improved repair (CASSANDRA-3362, 2699) >>>>>> >>>>>> Of course, we're planning some new features as well: >>>>>> - triggers (CASSANDRA-1311) >>>>>> - improved query fault tolerance (CASSANDRA-4705) >>>>>> - row size limits (CASSANDRA-3929) >>>>>> - cql3 integration for hadoop (CASSANDRA-4421) >>>>>> - improved caching (CASSANDRA-1956, 2864) >>>>>> >>>>>> -- >>>>>> Jonathan Ellis >>>>>> Project Chair, Apache Cassandra >>>>>> co-founder, http://www.datastax.com >>>>>> @spyced >>>>>> >>>> >>>> >>>> >>>> -- >>>> Jonathan Ellis >>>> Project Chair, Apache Cassandra >>>> co-founder, http://www.datastax.com >>>> @spyced >>> >>
