I'm also all in for a query language. There has been some excellent reasons already posted, but I have another good reason why a QL would be better: maintaining the cluster.
Due to 0.7 the Thrift API has now multiple structures and functions to: - define indexes - create/drop/rename new column families - altering keyspaces (like replication factor) - describe keyspace - truncate a keyspace and so on, I didn't even include all of those. I believe that it's stupid to expose all these as function calls and force client developers to implement some varying ways to call these functions from command line to maintain the database. In my opinion a uniform query language could make all these operations much easier and much more user friendly. Also the CLI could be much easier as it could just transfer the commands to the server. - Juho Mäkinen On Thu, Nov 4, 2010 at 9:59 PM, Eric Evans <eev...@rackspace.com> wrote: > On Thu, 2010-11-04 at 21:28 +0200, Ran Tavory wrote: >> A QL can shield clients from a class of changes, but OTOH will make >> clients have to compose the query strings, where with type safe >> libraries this job is somewhat easier. IMO in the near term >> introducing a query language will make client dev somewhat harder b/c >> of the (somewhat negligible) work of composing query strings and >> mostly b/c I don't expect the QL to be stable at v1 so still a moving >> target, but easier in the the long term mainly due to the hope that >> the QL will stabilize. > > I think you could argue that it makes all of this easier. Right now > from Java you serialize a type to a byte[] whereas with the query > language you'd serialize to a string term. That's a bit more effort out > of the gate for primitives like long for example, but consider the > venerable TimeUUID that causes so much frustration. I think it would be > much easier to take a timestamp and construct a term like > TIMEUUID(<timestamp>) (or whatever), especially since that would work > identically across all clients. > > And it's also worth pointing out that not all languages in use are > statically typed, so even in the case of an int, or a long, it'd be > easier (or as easy at least), to serialize that to a string like > 100000L, than it would be to pack a binary string in network-order. > > As for not being stable, well, yeah it's going to need to bake a bit > before being suitable for widespread use, but I raise it here not to > encourage everyone to transition now, but so that you can help shape the > outcome (if you're interested, of course). > >> One other benefit of query languages is that they make tooling a >> little easier, one does not have to come up with a specific CLI >> interpreter or a web interface with a set of input fields, you just >> have to type your QL into a text box or a terminal like you do with >> sql. >> Long term I think I'm in for a QL (although I have to think about the >> syntax you suggested) but I don't expect it to benefit client devs in >> the near term even if it was ready today as an alternative to thrift. >> >> One small question, does this language tunnel through avro or thrift >> calls? (Is >>> conn.execute() an avro or thrift call) > > It's avro for the simple reason that that's still sort of an > experimental code path and seemed a less controverial sandbox. When the > spec and implementation are complete, and if it gains suitable traction, > I'd actually like to explore a customized transport and serialization. > > -- > Eric Evans > eev...@rackspace.com > >
