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
