incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Basulto <>
Subject Re: Question regarding CQL
Date Sun, 06 Nov 2011 00:15:17 GMT
You're right Eric, you always need to make choices and tell advanteges
and drawbacks apart.

I think my question was based in the "fear", and the expirience. It's
like saying xQL always makes me shiver.

Also I was thinking, if Google did it (with GQL for AppEngine) then,
it's nothing to worry about. Just to keep things simple.

Thank you again for your help!

El día 2 de noviembre de 2011 00:44, Eric Evans <> escribió:
> On Tue, Nov 1, 2011 at 9:36 PM, Santiago Basulto
> <> wrote:
>> Sorry Eric, i think you misunderstood me. I'm not criticizing
>> (speaking against) CQL. As I said i watched your presentation, and i
>> agree with you. After all, you guys are software engineers and you
>> know what you're doing.
> That's OK, I didn't take it as a criticism, (and I don't always know
> what I'm doing, either :)).
>> I'm just asking if you have thought about it, and in that case, how to
>> keep it simple (if that's the desire, maybe there is some change of
>> "politic" and you have agreed that it will become a little bit more
>> big and complex, that would be another question though.).
> You seem to be starting from a position that a query language, as
> opposed to a Thrift-based RPC for example, results in greater overall
> complexity and less performance.  I disagree with this supposition.
> Let's take a query optimizer for instance (since that was among the
> examples you provided).
> A query optimizer is not something that becomes necessary because
> you're using a query language, it becomes necessary when there is more
> than one way to carry out the query, and you need to choose the most
> optimal.  This could apply to any type of interface, including a
> Thrift-based RPC like the one Cassandra has traditionally supported.
> I would assume that when (if!) we ever need a query optimizer, it's
> because we've picked up some interesting new capabilities that justify
> the additional complexity.
>> After all, there is one trade off that's inevitable: Client load vs
>> Server loads, i mean, if the idea is to keep client's "load,
>> complexity and intelligence" down, then the "server" will have to
>> handle it in some point.
> If pushing query abstraction to the server makes the server more
> complex, that is definitely a trade-off worth making.
>> Something more: Sorry for my english and thank you for listening and helping.
>> El día 1 de noviembre de 2011 21:41, Eric Evans <> escribió:
>>> On Tue, Nov 1, 2011 at 2:52 PM, Santiago Basulto
>>> <> wrote:
>>>> I've been taking a look at Cassandra code for a while (since last
>>>> year) and using and trying it "in home". Nowdays i've started to take
>>>> a look at the "new stuff", more precisely to CQL. I think it's great,
>>>> I mean, just taking a look at Eric presentation
>>>> ( makes you
>>>> love just it.
>>>> But, now i'm wondering: isn't it a one-way path? The kind you never
>>>> returns? I mean, if the Cassandra starts to grow in complexity, and
>>>> the datamodel extends a little bit, and everything start to grow, and
>>>> things like "query parsing", "query execution planning", "query
>>>> optimization" start to arise, would't it go against the first "simple,
>>>> fast" philosophy of the beginning?
>>> I know it's bad form to answer a question with a question, but how is
>>> this any different than any other type of query interface?  Or to put
>>> it another way, what is it about a query language that you find
>>> inherently complex?
>>> --
>>> Eric Evans
>>> Acunu | | @acunu
>> --
>> Santiago Basulto.-
> --
> Eric Evans
> Acunu | | @acunu

Santiago Basulto.-

View raw message