On Thu, Oct 28, 2010 at 1:40 PM, Eric Evans <eev...@rackspace.com> wrote: > > One solution to this is to implement a server-side query language, with > simple language drivers that manage all of the common functionality in a > consistent way (statement preparation, connection pooling, etc). > Library maintainers would then build their idiomatic interfaces on top > of these, (and I imagine, remove a metric crap-ton of code in the > process). > > To this end I've been playing with exactly that. I have enough to do > simple reads and writes, and I have stubbed out drivers for Java and > Python. I'm seeking community feedback to gauge interest, and to > satisfy the much needed desire to bike-shed. :) > > http://github.com/eevans/cassandra/tree/CQL > > You need to be sure you're checking out the "CQL" branch.
Meta-comment: You probably should not call it CQL. That name is already used in multiple standards for similar purposes. These aren't dead standards either, for some types of non-SQL database applications you are required to implement them. I once wrote a query language bridge between a couple CQL database standards, and the current mess already confuses the hell out of people. It would not surprise me if someone is working on a CQL implementation (pick your standard) that uses Cassandra as a backend since it would be a good fit for some use cases. To highlight the insanity of the "CQL" namespace, some government applications require implementation of two CQL standards where the "CQL" acronym expands to the *exact same name* and fill almost identical roles. This creates several levels of hell for developers. A less non-unique name would probably be beneficial. :-) -- J. Andrew Rogers
