Fair enough. I do have to keep reminding myself that a REST interface requires text. And it does make more sense, at least, when coming from a human as opposed to when you make a computer spend cycles converting binary to text just so another computer can spend cycles turning it back again.
On Sun, Jun 5, 2011 at 8:01 PM, aaron morton <aa...@thelastpickle.com> wrote: > From what I've seen of CQL there is no comparison between the potential > complexity of a CQL statement and that of a SQL statement. IMHO CQL is more > or less a human readable form of the current API, it does not add features. > SQL statements are arbitrarily complex and may generate many possible query > plans which need to be somehow compared and optimised. > > I'll add another pro to using CQL, it will be a lot easier for people to > describe a query they have sent to the server. It will make the helping > people using multiple languages a bit easier if they can grab a log record > and post the query they sent. > > I'm keen to see how it goes. > > Cheers > > ----------------- > Aaron Morton > Freelance Cassandra Developer > @aaronmorton > http://www.thelastpickle.com > > On 6 Jun 2011, at 03:27, Eric Evans wrote: > >> On Sun, 2011-06-05 at 00:51 -0400, Jeffrey Kesselman wrote: >>> Is CQL really the path for the future for Cassandra? >> >> CQL is no more or less "official" than the Thrift interface, and TTBMK, >> there is no secret cabal that met to decide it would be The Way. People >> will use what works best for them, and if a de facto standard emerges >> (it usually does), then so much the better. >> >>> It seems to me by introducing a textual language that has to be parsed >>> and understood, you are adding back in some of the inefficiency of >>> SQl... >> >> I think this "inefficiency" remains to be proven. Or if it is less >> inefficient, if it is enough so to warrant a discussion. >> >> No matter what the technology, you have to have a client send a query to >> the server structured in some way. Once received, the server has to >> "parse" that structure before it can act. What is different, is that >> CQL structures the query in a human-readable string, and Thrift >> structures it as a hierarchy of records serialized to binary. >> >> It may be true that CQL parsing has higher overhead (Thrift does more >> object creation and is likely worse on gc), but Cassandra nodes are >> typically limited by disk IO and have loads of idle processor time. I >> might be biased, but I think it is easy to justify considering how much >> easier CQL makes things. >> >>> 2011/6/4 aaron morton <aa...@thelastpickle.com>: >>>> May be wrong but as far as I know thrift is still the official API, for >>>> now. >>>> CQL is in it's first release and still has a few things to be added to >>>> it https://issues.apache.org/jira/browse/CASSANDRA-2472 . That said, jump >>>> in >>>> and try it out :) >>>> The best documentation I can point you to is >>>> https://github.com/apache/cassandra/blob/cassandra-0.8.0/doc/cql/CQL.textile >>>> There are Java, Python and Twisted Python drivers in the source tree under >>>> the drivers/ directory. >>>> Hope that helps. >>>> ----------------- >>>> Aaron Morton >>>> Freelance Cassandra Developer >>>> @aaronmorton >>>> http://www.thelastpickle.com >>>> On 5 Jun 2011, at 04:16, Yonder wrote: >>>> >>>> Hi, >>>> >>>> In Cassandra 0.8, CQL become the primary client interface, but I don't know >>>> how to use it in a non-command line env. I could not find out any how-to do >>>> docs in Wiki or DataStax's website. >> >> -- >> Eric Evans >> eev...@rackspace.com >> > > -- It's always darkest just before you are eaten by a grue.
