> Java you serialize a type to a byte[] whereas with the query > language you'd serialize to a string term The "serializing to a byte[]" part is what the RPC libraries exist for. With a string serialization format, you are setting all of your clients up to become string concatenation engines with an ad-hoc format defined by your spec: essentially, duplicating Avro and Thrift.
> TIMEUUID(<timestamp>) Note that this same approach is possible in Avro by adding a union type: it is not dependent on String serialization. > to serialize that to a string like > 100000L, than it would be to pack a binary string in network-order I don't think you are giving client library devs enough credit: this only needs to be implemented once, and I'm sure they're capable. -----Original Message----- From: "Eric Evans" <eev...@rackspace.com> Sent: Thursday, November 4, 2010 2:59pm To: client-dev@cassandra.apache.org Subject: Re: Calling all library maintainers 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
