Those concerns of yours came from my post (probably). I'd just like to
explain. Obviously no one is going to purposely not test thrift as we go
forward, and hopefully thrift users will gain benefits from future
releases in terms of performance and the like. The core cassandra devs
i've worked w
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
>
>
> > 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,
On Thu, Mar 13, 2014 at 4:14 PM, Nate McCall wrote:
> Sure:
> https://speakerdeck.com/sungjuly/apache-usergrid-internal
>
> Slide #21 and on goes over the entity model in detail. Particularly
> interesting:
> #36
> #40
> #55-#61
>
> Essentially, Usergrid supports *all* of the basic mongo CRUD ope
Sure:
https://speakerdeck.com/sungjuly/apache-usergrid-internal
Slide #21 and on goes over the entity model in detail. Particularly
interesting:
#36
#40
#55-#61
Essentially, Usergrid supports *all* of the basic mongo CRUD operations on
top of Cassandra, passing all of their test cases that don't
You should probably give more details of those two data models for
those of us who have contributed neither to usergrid nor the mongodb
emulator. :)
On Thu, Mar 13, 2014 at 9:10 AM, Nate McCall wrote:
> After discussing this the past few days with a couple of folks, yes, I
> don't think maintain
After discussing this the past few days with a couple of folks, yes, I
don't think maintaining the currently incubating Usergrid (
https://usergrid.incubator.apache.org/) will be possible.
Basically, how would you do what are essentially container collections of
arbitrary runtime-definable UDTs?
"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."
I was just recently putting my energy into 4 thrift tickets, I then was
planning to help out on some CQL issues. But then this happened which I
feel was directly aimed
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
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
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 wrote:
>> If any new use cases
>> come to light that can be done with Thrift but not CQL, we will commit
>> to suppo
> 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 i
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
On Wed, Mar 12, 2014 at 1:38 PM, Edward Capriolo 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.
-
", 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 wrote:
> +1 to Jonathan's proposal.
>
>
> On Tue, Mar 11, 2014 at 6:00 PM, Jonathan Ellis wrote:
>
> > CQL3 is almost two years ol
+1 to Jonathan's proposal.
On Tue, Mar 11, 2014 at 6: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
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 wrote:
>
> If you are using thrift there probably isn't a reaso
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()
On Tue, Mar 11, 2014 at 6:53 PM, Joe Stein 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 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.
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
ah! cool, thanks!
On Tue, Mar 11, 2014 at 7:55 PM, Brandon Williams wrote:
> On Tue, Mar 11, 2014 at 6:53 PM, Joe Stein 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/ca
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 wrote:
> I didn't mean a someone should maintain a for
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 wrote:
>
> +1,
>
> altho s
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 mar
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
develope
+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 simp
Sorry, I am not your team. But I do care native api.
A native api has much more impacts than anybody expected. Few reasons list here,
1. Using native api can help understand Cassandra DB much deeper.
2. Native api can support unusual customer with special needs. In some cases,
basic and high perf
I will move on. I --coincidentally-- happen to have just added a thrift
feature
http://www.edwardcapriolo.com/roller/edwardcapriolo/entry/thrift_isn_t_going_anywhere.
I also have 2-3 jira's open to add thrift features.
Seems like an interesting time to call a vote that effectively adds
language th
Nobody can seriously use or develop against Cassandra with only the
raw Thrift generated code either, so I agree that this is really a
different discussion.
On Tue, Mar 11, 2014 at 3:38 PM, Edward Capriolo wrote:
> "I am confused how any of this is relevant to Jonathan's original email."
>
> Here
"I am confused how any of this is relevant to Jonathan's original email."
Here is how:
I believe if native is the new official transport, Cassandra should include
the Java driver source code with the project.
Without the driver code inside the project how can someone use/develop the
software.
I am confused how any of this is relevant to Jonathan's original email.
On Tue, Mar 11, 2014 at 3:13 PM, Edward Capriolo wrote:
> "How about the myriad of thrift wrappers that aren't in-tree either?"
>
> How about all the times we trashed hbase saying "hbase treats non java
> people like second
If only some languages have support via a third party entity everyone who
does not have support is a second class citizen.
On Tue, Mar 11, 2014 at 4:16 PM, Jonathan Ellis wrote:
> What part of the native protocol makes any language a second class citizen?
>
> On Tue, Mar 11, 2014 at 3:13 PM, Edw
What part of the native protocol makes any language a second class citizen?
On Tue, Mar 11, 2014 at 3:13 PM, Edward Capriolo wrote:
> "How about the myriad of thrift wrappers that aren't in-tree either?"
>
> How about all the times we trashed hbase saying "hbase treats non java
> people like seco
"How about the myriad of thrift wrappers that aren't in-tree either?"
How about all the times we trashed hbase saying "hbase treats non java
people like second class citizens"
http://mail-archives.apache.org/mod_mbox/hbase-user/201108.mbox/%3ccafk14gsrnysj_oev2_utwc-+u4ssdmdsmp2dgrst90hoypw...@ma
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 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
How about the myriad of thrift wrappers that aren't in-tree either?
On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo 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 data
"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 wrote:
> On Tue, Mar 11, 2014 at 2:24 PM,
On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo 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 e
"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 cas
I¹m +1.
We¹ve had one foot out the door for a while now.
We are throwing resources at CQL. (e.g. storm-cassandra-cql) And we are
slowing support for the thrift-based implementation (e.g. storm-cassandra).
Alas poor Thrift, I knew him (well).
-brian
---
Brian O'Neill
Chief Technology Officer
On Tue, Mar 11, 2014 at 1:37 PM, Edward Capriolo wrote:
>
> 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.
>
The native protocol spec is the source
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
+1
But there is still room for improvement :)
https://issues.apache.org/jira/browse/CASSANDRA-6586
-M
On 3/11/14, 10:00, 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 one
+1
On Tue, Mar 11, 2014 at 12: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 a
+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 wrote:
> RIP Thrift :)
> +1 with "We will retain it for backwards co
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 wrote:
> As someone who has written a thrift wrapper, +1
>
>
> On Tue, Mar 11, 2014 at 12:00 PM, Jonathan Ellis
> wrote
As someone who has written a thrift wrapper, +1
On Tue, Mar 11, 2014 at 12: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
+1
fare thee well, thrift...
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 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
51 matches
Mail list logo
