This brainstorming idea has already been -1 ed in jira. ROFL.
On Wed, Mar 12, 2014 at 12:26 PM, Tupshin Harper <tups...@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 <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?). >>>>> >>>>> >>>> >> >
