Ed- I understand and respect your enthusiasm for Thrift, but it's ship has sailed. Yes- if you understand the low level thrift API I'm sure you can have a rewarding experience, but as someone who wrote a client and had to abstract thrift...I don't have many kind words, and I certainly have less hair on my head...
Every line of code ever written has the chance of bugs and thankfully this project has a super dedicated group of people who are very very responsive at fixing those. The sorting and paging bugs might not have happened in thrift because that logic is and has always been pushed onto the client. (Where there are also lots of bugs). I like the model where the bug is fixed once for all languages and clients personally... CQL has worked for me in 9 different sets of application logic as of now..and C* is more accessible to others because of it. Application code is simpler, client code is simpler, learning curve for new uses is easier. Win. Win. Win. IMHO, If you put 1/4 of the energy into CQL that you do into fighting for Thrift, I'm scared to think how amazing CQL would be. Best, Michael > On Mar 13, 2014, at 5:59 AM, "Edward Capriolo" <edlinuxg...@gmail.com> wrote: > > 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. =========================================================== JOIN US! Live webinar featuring 451 Research & West Windsor Township: Best Practices in Security Convergence March 18 at 10am PDT. RSVP at http://www.barracuda.com/451webinar
