@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?).
>>>
>>>
>>
