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
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 suppo
36 matches
Mail list logo
