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 <eev...@acunu.com> escribió: > 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 :)). >Yo >> 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 > -- Santiago Basulto.-
