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
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
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
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
+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
, 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:
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
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
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
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
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
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
+1
fare thee well, thrift...
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
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
+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
+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
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
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
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
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
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()
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
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
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:
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
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:
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
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
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
30 matches
Mail list logo
