There was a paging bug in 2.0 and a user just reported a bug sorting a one row dataset.
So if you want to argue cql has surpassed thrift in all ways, one way it clearly has not is correctness. To demonatrate, search the changelog for cql bugs that return wrong result. Then do the same search for thrift bugs that return the wrong result and compare. If nubes to the ml can pick up bugs and performance regressions it is a serious issue. On Wednesday, March 12, 2014, Jonathan Ellis <jbel...@gmail.com> wrote: > I don't know if an IN query already does this without source diving, > but it could certainly do so without needing extra syntax. > > On Wed, Mar 12, 2014 at 7:16 PM, Nicolas Favre-Felix <nico...@acunu.com> wrote: >>> 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. >> >> Hello, >> >> (going back to the original topic...) >> >> I just wanted to point out that there is in my opinion an important >> use case that is doable in Thrift but not in CQL, which is to fetch >> several CQL rows from the same partition in a single isolated read. We >> lose the benefit of partition-level isolation if there is no way to >> read rows together. >> Of course we can perform range queries and even scan over >> multi-dimensional clustering keys with CASSANDRA-4851, but we still >> can't fetch rows using a set of clustering keys. >> >> I couldn't find a JIRA for this feature, does anyone know if there is one? >> >> Cheers, >> Nicolas >> >> -- >> For what it's worth, +1 on freezing Thrift. > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder, http://www.datastax.com > @spyced > -- Sorry this was sent from mobile. Will do less grammar and spell check than usual.
