cassandra-client-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <eev...@rackspace.com>
Subject Re: Calling all library maintainers
Date Thu, 04 Nov 2010 19:59:52 GMT
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
eevans@rackspace.com


Mime
View raw message