> How can a TimeUUIDType be expressed in Avro using a union?
With syntax very similar to the syntax you described: define a record called
TimeUUID which takes a single timestamp parameter.
-----Original Message-----
From: "Eric Evans" <eev...@rackspace.com>
Sent: Friday, November 5, 2010 8:44am
To: client-dev@cassandra.apache.org
Subject: Re: Calling all library maintainers
On Fri, 2010-11-05 at 02:43 -0500, Stu Hood wrote:
> > 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.
I was referring to keys and column names and values which are typed as
binary in both 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.
How can a TimeUUIDType be expressed in Avro using a union?
> > 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.
I was speaking to the relative difficulty in serializing a type using
one method or another. In other words, in Python it becomes:
import struct; struct.pack('>d', val)
versus
str(val)
Both of which only need to be implemented once, of course.
> -----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
