incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: Proposal: freeze Thrift starting with 2.1.0
Date Wed, 12 Mar 2014 20:01:13 GMT
This brainstorming idea has already been -1 ed in jira. ROFL.


On Wed, Mar 12, 2014 at 12:26 PM, Tupshin Harper <tupshin@tupshin.com>wrote:

> OK, so I'm greatly encouraged by the level of interest in this. I went
> ahead and created https://issues.apache.org/jira/browse/CASSANDRA-6846,
> and will be starting to look into what the interface would have to look
> like. Anybody feel free to continue the discussion here, email me
> privately, or comment on ticket with your thoughts.
>
> -Tupshin
>
>
> On Wed, Mar 12, 2014 at 12:21 PM, Peter Lin <woolfel@gmail.com> wrote:
>
>>
>> @Tupshin
>> LOL, there's always enough rope to hang oneself. I agree it's badly
>> needed for folks that really do need more "messy" queries. I was just
>> discussing a similar concept with a co-worker and going over the pros/cons
>> of various approaches to realizing the goal. I'm still digging into Presto.
>> I saw some people are working on support for cassandra in presto.
>>
>>
>>
>> On Wed, Mar 12, 2014 at 12:15 PM, Tupshin Harper <tupshin@tupshin.com>wrote:
>>
>>> Peter,
>>>
>>> I didn't specifically call it out, but the interface I just proposed in
>>> my last email would be very much with the goal of "make writing complex
>>> queries less painful and more efficient." by providing a deep integration
>>> mechanism to host that code.  It's very much a "enough rope to hang
>>> ourselves" approach, but badly needed,  IMO
>>>
>>> -Tupshin
>>> On Mar 12, 2014 12:12 PM, "Peter Lin" <woolfel@gmail.com> wrote:
>>>
>>>>
>>>> @Nate
>>>> I don't want to change the separation of components in cassandra. My
>>>> ultimate goal is "make writing complex queries less painful and more
>>>> efficient." How that becomes reality is anyone's guess. There's different
>>>> ways to get there. I also like having a plugging transport layer, which is
>>>> why I feel sad every time I hear people say "thrift is dead" or "thrift is
>>>> frozen beyond 2.1" or "don't use thrift". When people ask me what to learn
>>>> with Cassandra, I say both thrift and CQL. Not everyone has time to read
>>>> the native protocol spec or dive into cassandra code, but clearly "some"
>>>> people do and enjoy it. I understand some people don't want the burden of
>>>> maintaining Thrift, and it's totally valid. It's up to those that want to
>>>> keep thrift to make sure patches and enhancements are well tested and solid.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Mar 12, 2014 at 11:52 AM, Nate McCall <nate@thelastpickle.com>wrote:
>>>>
>>>>> IME/O one of the best things about Cassandra was the separation of
>>>>> (and I'm over-simplifying a bit, but still):
>>>>>
>>>>> - The transport/API layer
>>>>> - The Datacenter layer
>>>>> - The Storage layer
>>>>>
>>>>>
>>>>> > 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.
>>>>>
>>>>> In tree, or even documented, I agree completely. I've never argued
>>>>> CQL3 is not the best approach for new users.
>>>>>
>>>>> But I've been around long enough that I know precisely what I want to
>>>>> do sometimes and any general purpose API will get in the way of that.
>>>>>
>>>>> I would like the transport/API layer to at least remain pluggable
>>>>> ("hackable" if you will) in it's current form. I really just want to
be
>>>>> able to create my own *Daemon - as I can now - and go on my merry way
>>>>> without having to modify any internals. Much like with compaction
>>>>> strategies and SSTable components.
>>>>>
>>>>> Do you intend to change this current behavior of allowing a custom
>>>>> transport without code modification? (as opposed to changing the daemon
>>>>> class in a script?).
>>>>>
>>>>>
>>>>
>>
>

Mime
View raw message