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 <wool...@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 <tups...@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" <wool...@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 <n...@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?).
>>>>
>>>>
>>>
>
