Re: Proposal: freeze Thrift starting with 2.1.0
FWIW even for new development we have found thrift preferable to CQL. Others have have a different experience and that's cool. It's certinaly made it less intimidating to new users when explaining Cassandra. I'm very concerned at the sentiments in this thread about not testing or upgrading to 2.1 being a dumb idea. The thing we value most from Cassandra is that it works. Operability, stability, and robustness are by far the most important traits. I can deal with wrapping APIs and transport layers. Dealing with untested releases is much more complicated.
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
Re: Proposal: freeze Thrift starting with 2.1.0
+1 to Jonathan's proposal. On Tue, Mar 11, 2014 at 6: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
Re: Proposal: freeze Thrift starting with 2.1.0
, I don't know of any use cases for Thrift that can't be done in CQL Can dynamic composites be used from CQL? On Wed, Mar 12, 2014 at 4:44 AM, Sylvain Lebresne sylv...@datastax.comwrote: +1 to Jonathan's proposal. On Tue, Mar 11, 2014 at 6: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
Re: Proposal: freeze Thrift starting with 2.1.0
On Wed, Mar 12, 2014 at 1:38 PM, Edward Capriolo edlinuxg...@gmail.comwrote: , I don't know of any use cases for Thrift that can't be done in CQL Can dynamic composites be used from CQL? Sure, you can use any AbstractType Class you want as type in CQL the same way you would do it with the thrift API. -- Sylvain On Wed, Mar 12, 2014 at 4:44 AM, Sylvain Lebresne sylv...@datastax.com wrote: +1 to Jonathan's proposal. On Tue, Mar 11, 2014 at 6: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
Re: Proposal: freeze Thrift starting with 2.1.0
I am glad the project has is adoptimg unambigious language of their position. It is nice to have the clarity that volunteer efforts to add features to thrift will be rejected. This is a shining example of how a volunteer apache software foundation project should be run. if users are attempting to add features, call a vote and add language to stop them. +1 On Wednesday, March 12, 2014, Sylvain Lebresne sylv...@datastax.com wrote: On Wed, Mar 12, 2014 at 1:38 PM, Edward Capriolo edlinuxg...@gmail.com wrote: , I don't know of any use cases for Thrift that can't be done in CQL Can dynamic composites be used from CQL? Sure, you can use any AbstractType Class you want as type in CQL the same way you would do it with the thrift API. -- Sylvain On Wed, Mar 12, 2014 at 4:44 AM, Sylvain Lebresne sylv...@datastax.com wrote: +1 to Jonathan's proposal. On Tue, Mar 11, 2014 at 6: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 -- Sorry this was sent from mobile. Will do less grammar and spell check than usual.
Re: Proposal: freeze Thrift starting with 2.1.0
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.
Re: Proposal: freeze Thrift starting with 2.1.0
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
Proposal: freeze Thrift starting with 2.1.0
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
Re: Proposal: freeze Thrift starting with 2.1.0
Sounds good to me, I was under an impression that we already did freeze Thrift tho... On Tue, Mar 11, 2014 at 10:00 AM, 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
Re: Proposal: freeze Thrift starting with 2.1.0
+1 fare thee well, thrift...
Re: Proposal: freeze Thrift starting with 2.1.0
As someone who has written a thrift wrapper, +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
Re: Proposal: freeze Thrift starting with 2.1.0
RIP Thrift :) +1 with We will retain it for backwards compatibility. Hopefully most people will move out of thrift by 2.1 On Tue, Mar 11, 2014 at 10:18 AM, Brandon Williams dri...@gmail.com wrote: As someone who has written a thrift wrapper, +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
Re: Proposal: freeze Thrift starting with 2.1.0
+1 Although lots of people are still using thrift, it's not a good use of time to maintain two interfaces when one is clearly better. But, yes, retaining thrift for some time is important. On 11 March 2014 17:27, sankalp kohli kohlisank...@gmail.com wrote: RIP Thrift :) +1 with We will retain it for backwards compatibility. Hopefully most people will move out of thrift by 2.1 On Tue, Mar 11, 2014 at 10:18 AM, Brandon Williams dri...@gmail.com wrote: As someone who has written a thrift wrapper, +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
Re: Proposal: freeze Thrift starting with 2.1.0
+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
Re: Proposal: freeze Thrift starting with 2.1.0
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
Re: Proposal: freeze Thrift starting with 2.1.0
I hope you're not arguing that Thrift IDL qualifies as a driver, because that's ridiculous. On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo edlinuxg...@gmail.com wrote: Other databases treat this issue differently, and there are a set of tradeoffs. Mysql's decision may not be the best for Cassandra. Do you know of any other database that does not provide it's own driver? On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs ty...@datastax.com wrote: On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo edlinuxg...@gmail.com wrote: The native protocol spec is the source of truth. If Cassandra's behavior doesn't match the spec, it's a bug. Likewise for any drivers. I'm not sure how this makes it unclear whether a bug is server-side or client-side. Maybe an example scenario would be useful? In the near future. I am a cassadra committer. I find a bug between cassanda server and java client driver. For example, the server is sending an unsigned by the other is expecting a signed byte. As a cassandra committer I can only change half of the equation. I change the cassandra server, that would break the ruby-client. That won't work will it? My only recourse as a cassandra committer is to go ask some other entity to change their driver. The solution would be: 1. Update the spec (for the current protocol version) to specify that it's an unsigned byte. (Perhaps add a note that this will change in the next protocol version.) 2. In the next version of the protocol, specify that the byte is signed and change Cassandra's behavior to match this. Note this change in the changes section of the spec. This doesn't break existing clients and it allows the behavior to be fixed with the next protocol version. (Cassandra also supports multiple versions of the native protocol, fwiw.) This means the spec is ambiguous. In that case, I imagine the proper solution would be to create a jira ticket and decide how to resolve the ambiguity in the spec. Yes but then after you change the spec, one client is broken and one is not. Is one client more official then another? Do you change the spec to match the client with more users. You change the spec to match whatever Cassandra is doing. It's not a matter of what driver is more popular. Think about mysql. Does it ship with a driver? Yes. Who writes the driver? mysql. Where is the source code for this driver? Inside the same repository as the server. Cassandra should be the same way. Other databases treat this issue differently, and there are a set of tradeoffs. Mysql's decision may not be the best for Cassandra. -- Tyler Hobbs DataStax http://datastax.com/ -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: Proposal: freeze Thrift starting with 2.1.0
On Tue, Mar 11, 2014 at 6:53 PM, Joe Stein crypt...@gmail.com wrote: Is there a wiki page for the protocol spec? I googled a little but my google fu is off today :( We keep that in-tree: https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v2.spec
Re: Proposal: freeze Thrift starting with 2.1.0
With support officially deprecated that will be the only way to go. If a user wants to add a function to thrift they will have to fork off cassandra, code the function themselves write the internals, manage the internals. I see this as being a very hard task because the server could change rapidly with no regards to them. Also this could cause a proliferation of functions. Could you imagine a thrift server with 300 methods :). This is why I think keeping the support in trunk and carefully adding things would be sane, but seemingly no one wants to support it at all so a fork is probably in order. On Tue, Mar 11, 2014 at 7:46 PM, Russ Bradberry rbradbe...@gmail.comwrote: I would like to suggest the possibility of having the interface somewhat pluggable so another project can provide the Thrift interface as a drop in JAR. Thoughts? Sent from my iPhone On Mar 11, 2014, at 7:26 PM, Edward Capriolo edlinuxg...@gmail.com wrote: If you are using thrift there probably isn't a reason to upgrade to 2.1 What? Upgrading gets you performance regardless of your api. We have already gone from no new feature talk to less enphisis on testing. How comforting. On Tuesday, March 11, 2014, Dave Brosius dbros...@mebigfatguy.com wrote: +1, altho supporting thrift in 2.1 seems overly conservative. If you are using thrift there probably isn't a reason to upgrade to 2.1, in fact doing so will become an increasingly dumb idea as lesser and lesser emphasis will be placed on testing with 2.1+. This would allow us to greatly simplify the code footprint in 2.1 On 03/11/2014 01:00 PM, Jonathan Ellis 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 -- Sorry this was sent from mobile. Will do less grammar and spell check than usual.
Re: Proposal: freeze Thrift starting with 2.1.0
I meant to say that thrift provides a facade over the StorageProxy. Without thrift the only user of the cassandra engine would be CQL. At that point the storage engine would likely evolve less usable and plugable. Thrift has it easy because it has friendly methods like StorageProxy.batch_mutate() to call. Without that project level support many of the things that plugable_application_x would want to call buried inside a set of interfaces that are designed only with the CQL use case in mind. In a simple case imagine something you want inside cool_new_interface_x is marked private in cassandra. You then need to fork the code, or convince upstream to make it accessible. BTW I think you know, but I already took a stab at what your describing, pluggable, rest, and jvm language (https://github.com/zznate/intravert-ug) On Tue, Mar 11, 2014 at 8:16 PM, Russell Bradberry rbradbe...@gmail.comwrote: I didn't mean a someone should maintain a fork of Cassandra. More like something that could be dropped in. Just like clients have to keep up with the server, a project like this would also. I think if the interface was pluggable it would also allow others to expand and come up with new interfaces that can possibly expand the user base. One example would be a built in REST interface that doesn't rely on an external web server that translates requests to CQL, just drop in a JAR and the interface comes available. This would also lend itself to allow anyone to write an interface in any (JVM) language they want, if they want to add external stored procedures via this interface then they would be able to. I'm for the removal of Thrift in the trunk, but I think there is a use-case for an extensible interface. I still seem to remember there was a few angry users when Avro was removed. On Tue, Mar 11, 2014 at 8:04 PM, Edward Capriolo edlinuxg...@gmail.com wrote: With support officially deprecated that will be the only way to go. If a user wants to add a function to thrift they will have to fork off cassandra, code the function themselves write the internals, manage the internals. I see this as being a very hard task because the server could change rapidly with no regards to them. Also this could cause a proliferation of functions. Could you imagine a thrift server with 300 methods :). This is why I think keeping the support in trunk and carefully adding things would be sane, but seemingly no one wants to support it at all so a fork is probably in order. On Tue, Mar 11, 2014 at 7:46 PM, Russ Bradberry rbradbe...@gmail.com wrote: I would like to suggest the possibility of having the interface somewhat pluggable so another project can provide the Thrift interface as a drop in JAR. Thoughts? Sent from my iPhone On Mar 11, 2014, at 7:26 PM, Edward Capriolo edlinuxg...@gmail.com wrote: If you are using thrift there probably isn't a reason to upgrade to 2.1 What? Upgrading gets you performance regardless of your api. We have already gone from no new feature talk to less enphisis on testing. How comforting. On Tuesday, March 11, 2014, Dave Brosius dbros...@mebigfatguy.com wrote: +1, altho supporting thrift in 2.1 seems overly conservative. If you are using thrift there probably isn't a reason to upgrade to 2.1, in fact doing so will become an increasingly dumb idea as lesser and lesser emphasis will be placed on testing with 2.1+. This would allow us to greatly simplify the code footprint in 2.1 On 03/11/2014 01:00 PM, Jonathan Ellis 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
Re: Proposal: freeze Thrift starting with 2.1.0
I didn't mean a someone should maintain a fork of Cassandra. More like something that could be dropped in. Just like clients have to keep up with the server, a project like this would also. I think if the interface was pluggable it would also allow others to expand and come up with new interfaces that can possibly expand the user base. One example would be a built in REST interface that doesn't rely on an external web server that translates requests to CQL, just drop in a JAR and the interface comes available. This would also lend itself to allow anyone to write an interface in any (JVM) language they want, if they want to add external stored procedures via this interface then they would be able to. I'm for the removal of Thrift in the trunk, but I think there is a use-case for an extensible interface. I still seem to remember there was a few angry users when Avro was removed. On Tue, Mar 11, 2014 at 8:04 PM, Edward Capriolo edlinuxg...@gmail.comwrote: With support officially deprecated that will be the only way to go. If a user wants to add a function to thrift they will have to fork off cassandra, code the function themselves write the internals, manage the internals. I see this as being a very hard task because the server could change rapidly with no regards to them. Also this could cause a proliferation of functions. Could you imagine a thrift server with 300 methods :). This is why I think keeping the support in trunk and carefully adding things would be sane, but seemingly no one wants to support it at all so a fork is probably in order. On Tue, Mar 11, 2014 at 7:46 PM, Russ Bradberry rbradbe...@gmail.com wrote: I would like to suggest the possibility of having the interface somewhat pluggable so another project can provide the Thrift interface as a drop in JAR. Thoughts? Sent from my iPhone On Mar 11, 2014, at 7:26 PM, Edward Capriolo edlinuxg...@gmail.com wrote: If you are using thrift there probably isn't a reason to upgrade to 2.1 What? Upgrading gets you performance regardless of your api. We have already gone from no new feature talk to less enphisis on testing. How comforting. On Tuesday, March 11, 2014, Dave Brosius dbros...@mebigfatguy.com wrote: +1, altho supporting thrift in 2.1 seems overly conservative. If you are using thrift there probably isn't a reason to upgrade to 2.1, in fact doing so will become an increasingly dumb idea as lesser and lesser emphasis will be placed on testing with 2.1+. This would allow us to greatly simplify the code footprint in 2.1 On 03/11/2014 01:00 PM, Jonathan Ellis 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 -- Sorry this was sent from mobile. Will do less grammar and spell check than usual.
Re: Proposal: freeze Thrift starting with 2.1.0
Is there a wiki page for the protocol spec? I googled a little but my google fu is off today :( One nice thing about Thrift is that the interface is human explanative and serializes into a format the computer likes too. With Apache Kafka it is a wire protocol and a lot of developers have developed against it. I think that is because of the documentation that was contributed to the community those developers were able to succeed https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocoland didn't feel left out. I have heard folks having built their platforms to support Cassandra on the thrift interface because they felt it as a tighter integration. I think it was as recently as last week at the Titan Graph DB talk at the NYC C* meetup. I have been recommending CQL3 for a 9 months now so if people have enough heads up time it should be alright but I don't know if the expectation is when 2.1 is coming out. Lastly, would 2.2 be released as 3.0? I ask because everything new would not be backwards compatible to anyone using the old interface? /*** Joe Stein Founder, Principal Consultant Big Data Open Source Security LLC http://www.stealth.ly Twitter: @allthingshadoop http://www.twitter.com/allthingshadoop / On Tue, Mar 11, 2014 at 7:26 PM, Edward Capriolo edlinuxg...@gmail.comwrote: If you are using thrift there probably isn't a reason to upgrade to 2.1 What? Upgrading gets you performance regardless of your api. We have already gone from no new feature talk to less enphisis on testing. How comforting. On Tuesday, March 11, 2014, Dave Brosius dbros...@mebigfatguy.com wrote: +1, altho supporting thrift in 2.1 seems overly conservative. If you are using thrift there probably isn't a reason to upgrade to 2.1, in fact doing so will become an increasingly dumb idea as lesser and lesser emphasis will be placed on testing with 2.1+. This would allow us to greatly simplify the code footprint in 2.1 On 03/11/2014 01:00 PM, Jonathan Ellis 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 -- Sorry this was sent from mobile. Will do less grammar and spell check than usual.
Re: Proposal: freeze Thrift starting with 2.1.0
I can agree with not liking the construction kit approach. Redis http://redis.io/commands 40 plus commands over telnet. elastic search: json over http: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-search.html couch db: json over http and javascript: http://docs.couchdb.org/en/latest/intro/tour.html mongo db: json over binary api, with javascript and in database map reduce. At this point it is just different strokes for different folks, some people want a query api because they dont get nosql and some dont. On Tue, Mar 11, 2014 at 8:35 PM, Jonathan Ellis jbel...@gmail.com wrote: I don't think we're well-served by the construction kit approach. It's difficult enough to evaluate NoSQL without deciding if you should run CQLSandra or Hectorsandra or Intravertandra etc. On Tue, Mar 11, 2014 at 7:16 PM, Russell Bradberry rbradbe...@gmail.com wrote: I didn't mean a someone should maintain a fork of Cassandra. More like something that could be dropped in. Just like clients have to keep up with the server, a project like this would also. I think if the interface was pluggable it would also allow others to expand and come up with new interfaces that can possibly expand the user base. One example would be a built in REST interface that doesn't rely on an external web server that translates requests to CQL, just drop in a JAR and the interface comes available. This would also lend itself to allow anyone to write an interface in any (JVM) language they want, if they want to add external stored procedures via this interface then they would be able to. I'm for the removal of Thrift in the trunk, but I think there is a use-case for an extensible interface. I still seem to remember there was a few angry users when Avro was removed. On Tue, Mar 11, 2014 at 8:04 PM, Edward Capriolo edlinuxg...@gmail.com wrote: With support officially deprecated that will be the only way to go. If a user wants to add a function to thrift they will have to fork off cassandra, code the function themselves write the internals, manage the internals. I see this as being a very hard task because the server could change rapidly with no regards to them. Also this could cause a proliferation of functions. Could you imagine a thrift server with 300 methods :). This is why I think keeping the support in trunk and carefully adding things would be sane, but seemingly no one wants to support it at all so a fork is probably in order. On Tue, Mar 11, 2014 at 7:46 PM, Russ Bradberry rbradbe...@gmail.com wrote: I would like to suggest the possibility of having the interface somewhat pluggable so another project can provide the Thrift interface as a drop in JAR. Thoughts? Sent from my iPhone On Mar 11, 2014, at 7:26 PM, Edward Capriolo edlinuxg...@gmail.com wrote: If you are using thrift there probably isn't a reason to upgrade to 2.1 What? Upgrading gets you performance regardless of your api. We have already gone from no new feature talk to less enphisis on testing. How comforting. On Tuesday, March 11, 2014, Dave Brosius dbros...@mebigfatguy.com wrote: +1, altho supporting thrift in 2.1 seems overly conservative. If you are using thrift there probably isn't a reason to upgrade to 2.1, in fact doing so will become an increasingly dumb idea as lesser and lesser emphasis will be placed on testing with 2.1+. This would allow us to greatly simplify the code footprint in 2.1 On 03/11/2014 01:00 PM, Jonathan Ellis 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.
Re: Proposal: freeze Thrift starting with 2.1.0
If there is someone with the time and resources to fork and keep thrift up to date, they could assumedly just push thrift updates back into master. i.e. If the goal is to reduce maintenance overhead for the core secs that's fine, but the it doesn't need to be frozen right? Perhaps it must be marked frozen for anyone with time and resources to continue enhancements to step out of the woodworks? If no one does, it stays frozen. __ Sent from iPhone On 12 Mar 2014, at 8:04 am, Edward Capriolo edlinuxg...@gmail.com wrote: With support officially deprecated that will be the only way to go. If a user wants to add a function to thrift they will have to fork off cassandra, code the function themselves write the internals, manage the internals. I see this as being a very hard task because the server could change rapidly with no regards to them. Also this could cause a proliferation of functions. Could you imagine a thrift server with 300 methods :). This is why I think keeping the support in trunk and carefully adding things would be sane, but seemingly no one wants to support it at all so a fork is probably in order. On Tue, Mar 11, 2014 at 7:46 PM, Russ Bradberry rbradbe...@gmail.comwrote: I would like to suggest the possibility of having the interface somewhat pluggable so another project can provide the Thrift interface as a drop in JAR. Thoughts? Sent from my iPhone On Mar 11, 2014, at 7:26 PM, Edward Capriolo edlinuxg...@gmail.com wrote: If you are using thrift there probably isn't a reason to upgrade to 2.1 What? Upgrading gets you performance regardless of your api. We have already gone from no new feature talk to less enphisis on testing. How comforting. On Tuesday, March 11, 2014, Dave Brosius dbros...@mebigfatguy.com wrote: +1, altho supporting thrift in 2.1 seems overly conservative. If you are using thrift there probably isn't a reason to upgrade to 2.1, in fact doing so will become an increasingly dumb idea as lesser and lesser emphasis will be placed on testing with 2.1+. This would allow us to greatly simplify the code footprint in 2.1 On 03/11/2014 01:00 PM, Jonathan Ellis 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 -- Sorry this was sent from mobile. Will do less grammar and spell check than usual.
Re: Proposal: freeze Thrift starting with 2.1.0
ah! cool, thanks! On Tue, Mar 11, 2014 at 7:55 PM, Brandon Williams dri...@gmail.com wrote: On Tue, Mar 11, 2014 at 6:53 PM, Joe Stein crypt...@gmail.com wrote: Is there a wiki page for the protocol spec? I googled a little but my google fu is off today :( We keep that in-tree: https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v2.spec
Re: Proposal: freeze Thrift starting with 2.1.0
If you are using thrift there probably isn't a reason to upgrade to 2.1 What? Upgrading gets you performance regardless of your api. We have already gone from no new feature talk to less enphisis on testing. How comforting. On Tuesday, March 11, 2014, Dave Brosius dbros...@mebigfatguy.com wrote: +1, altho supporting thrift in 2.1 seems overly conservative. If you are using thrift there probably isn't a reason to upgrade to 2.1, in fact doing so will become an increasingly dumb idea as lesser and lesser emphasis will be placed on testing with 2.1+. This would allow us to greatly simplify the code footprint in 2.1 On 03/11/2014 01:00 PM, Jonathan Ellis 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 -- Sorry this was sent from mobile. Will do less grammar and spell check than usual.
Re: Proposal: freeze Thrift starting with 2.1.0
I don't think we're well-served by the construction kit approach. It's difficult enough to evaluate NoSQL without deciding if you should run CQLSandra or Hectorsandra or Intravertandra etc. On Tue, Mar 11, 2014 at 7:16 PM, Russell Bradberry rbradbe...@gmail.com wrote: I didn't mean a someone should maintain a fork of Cassandra. More like something that could be dropped in. Just like clients have to keep up with the server, a project like this would also. I think if the interface was pluggable it would also allow others to expand and come up with new interfaces that can possibly expand the user base. One example would be a built in REST interface that doesn't rely on an external web server that translates requests to CQL, just drop in a JAR and the interface comes available. This would also lend itself to allow anyone to write an interface in any (JVM) language they want, if they want to add external stored procedures via this interface then they would be able to. I'm for the removal of Thrift in the trunk, but I think there is a use-case for an extensible interface. I still seem to remember there was a few angry users when Avro was removed. On Tue, Mar 11, 2014 at 8:04 PM, Edward Capriolo edlinuxg...@gmail.comwrote: With support officially deprecated that will be the only way to go. If a user wants to add a function to thrift they will have to fork off cassandra, code the function themselves write the internals, manage the internals. I see this as being a very hard task because the server could change rapidly with no regards to them. Also this could cause a proliferation of functions. Could you imagine a thrift server with 300 methods :). This is why I think keeping the support in trunk and carefully adding things would be sane, but seemingly no one wants to support it at all so a fork is probably in order. On Tue, Mar 11, 2014 at 7:46 PM, Russ Bradberry rbradbe...@gmail.com wrote: I would like to suggest the possibility of having the interface somewhat pluggable so another project can provide the Thrift interface as a drop in JAR. Thoughts? Sent from my iPhone On Mar 11, 2014, at 7:26 PM, Edward Capriolo edlinuxg...@gmail.com wrote: If you are using thrift there probably isn't a reason to upgrade to 2.1 What? Upgrading gets you performance regardless of your api. We have already gone from no new feature talk to less enphisis on testing. How comforting. On Tuesday, March 11, 2014, Dave Brosius dbros...@mebigfatguy.com wrote: +1, altho supporting thrift in 2.1 seems overly conservative. If you are using thrift there probably isn't a reason to upgrade to 2.1, in fact doing so will become an increasingly dumb idea as lesser and lesser emphasis will be placed on testing with 2.1+. This would allow us to greatly simplify the code footprint in 2.1 On 03/11/2014 01:00 PM, Jonathan Ellis 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 -- Sorry this was sent from mobile. Will do less grammar and spell check than usual. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: Proposal: freeze Thrift starting with 2.1.0
I would like to suggest the possibility of having the interface somewhat pluggable so another project can provide the Thrift interface as a drop in JAR. Thoughts? Sent from my iPhone On Mar 11, 2014, at 7:26 PM, Edward Capriolo edlinuxg...@gmail.com wrote: If you are using thrift there probably isn't a reason to upgrade to 2.1 What? Upgrading gets you performance regardless of your api. We have already gone from no new feature talk to less enphisis on testing. How comforting. On Tuesday, March 11, 2014, Dave Brosius dbros...@mebigfatguy.com wrote: +1, altho supporting thrift in 2.1 seems overly conservative. If you are using thrift there probably isn't a reason to upgrade to 2.1, in fact doing so will become an increasingly dumb idea as lesser and lesser emphasis will be placed on testing with 2.1+. This would allow us to greatly simplify the code footprint in 2.1 On 03/11/2014 01:00 PM, Jonathan Ellis 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 -- Sorry this was sent from mobile. Will do less grammar and spell check than usual.
