On Tue, Nov 1, 2011 at 9:36 PM, Santiago Basulto <santiago.basu...@gmail.com> 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 <eev...@acunu.com> escribió: >> On Tue, Nov 1, 2011 at 2:52 PM, Santiago Basulto >> <santiago.basu...@gmail.com> 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 >>> (http://www.datastax.com/2011/07/video-eric-evans-on-cql) 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 | http://www.acunu.com | @acunu >> > > > > -- > Santiago Basulto.- > -- Eric Evans Acunu | http://www.acunu.com | @acunu
