Let me preface this by saying: the fact that it looks like SQL doesn't bother me. But: I think this would be a terrible thing to _focus_ on. Something for contrib? Sure.
Most reasonable languages these days have a way to define what looks like a DSL: giving people a text DSL which is subject to injection attacks and can't be type checked without support from a client driver anyway is brain dead. There is a reason that 99% of clients that interact with a SQL server do so programmatically via a library: because that is an easier way to interact than via string concatenation. At least that way the library is performing the concatenation for you. Regarding performance: assuming optimized RPC libraries (which we do not yet have in Avro, and which Thrift is getting better at), serializing to a string and back will never be as performant as using a pre-parsed representation of the statement on both sides. "Oh but we can add prepared statements!" Poppycock. ---- > Truth is we've seen quite a bit of proliferation, and very little critical > mass. > forced to move in lock-step with Cassandra releases, that are never backward > compatible Expecting stable libraries or API pre-1.0 is not reasonable: neither the devs nor the users expect stability, and yet we are still able to guarantee compatibility within major versions. The stated problem is that backwards compatibility is hard to provide: if that is the core complaint, then changing to a text based serialization format with a sexy name in order to add backwards compatibility is a severe overreaction to the problem. Instead, I would propose evolving the API in a manner that simplifies it. Thanks, Stu -----Original Message----- From: "Eric Evans" <eev...@rackspace.com> Sent: Thursday, October 28, 2010 4:56pm To: dev@cassandra.apache.org Subject: Re: NoSQL, YesCQL? On Thu, 2010-10-28 at 14:46 -0700, Chip Salzenberg wrote: > Short answer: "YES Please, but we will still want a side channel for > minimum overhead." Ok. Though I'm not sure I agree with the "minimum overhead" argument. I've only done preliminary tests so far, but this seems on par (if not a little faster) than Thrift is, and no effort to optimize has been made (using a socket transport instead of HTTP for example would make a big difference). > Long answer: Query languages only work reliably when you have data > binding assistance (insert "Bobby Tables" xkcd here). However, they > do > have the wonderful property of evolving aggressively without requiring > upgrades of the driver plumbing. This is, of course, emphatically > *not* > true of anything like the current Thrift and Avro interfaces. So > that's > why I say "Yes." On the other hand, a very simple interface for very > simple queries has a lot of value, too; see, for example, > http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html > > So that's why I think we will still want to bypass the full language > for minimum latency in some circumstances. I'm also not sure I follow here either. Do you mean simple for the application developer? CQL-using code should be considerably simpler than the equivalent Thrift/Avro. Thanks for the feedback! -- Eric Evans eev...@rackspace.com
