Re: Proposal: freeze Thrift starting with 2.1.0
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.
Re: Proposal: freeze Thrift starting with 2.1.0
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
Re: Proposal: freeze Thrift starting with 2.1.0
Essentially, Usergrid supports *all* of the basic mongo CRUD operations on top of Cassandra, passing all of their test cases that don't use any out-of-the-way functions. Would it be possible to build something similar *solely* with CQL? If it's doable on top of thrift, it's doable on top of CQL, yes. Note that there is use cases (and usegrid might well be one) for which the CQL version will not look much better than the thrift one would (typically, if you want to use DynamicCompositeType, you will be back to manipulating your cell names and values as blob client side, the very same way you'd do with thrift). Still, it's possible, and even when it's not prettier with CQL than it is with thrift (and there is a very large amount of use cases where it is prettier with CQL), it's not worth either. This is exactly what I needed to know. Thank you - really. I'll look into this and see if there is something I can write up as a explanation/conversion example for folks in a similar situation. I'm fine with Thrift going away - I get the reasoning there. I just want to be able to hack against (against, not on) internals more easily. Let's first maybe agree that this relatively separated from the let's freeze the thrift API proposal of Jonathan? If we do agree on that, maybe this should be discussed separately (at least some other thread), so it doesn't make it sound like this is some disagreement over Jonathan's proposal? Fair enough. +1 (non-binding). -- - Nate McCall Austin, TX @zznate Co-Founder Sr. Technical Consultant Apache Cassandra Consulting http://www.thelastpickle.com
