The union would be to allow either 'bytes' or your 'TimeUUID' class, or any
other sugar classes that perform these operations on the server side.
-Original Message-
From: "Stu Hood"
Sent: Friday, November 5, 2010 11:33am
To: client-dev@cassandra.apache.org
Subject: Re: Calling all librar
> 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"
Sent: Friday, November 5, 2010 8:44am
To: client-dev@cassand
On Fri, Nov 5, 2010 at 11:40 AM, Gary Dusbabek wrote:
>>
>> I still think the query language is a good idea but I have one
>> negative point about it.
>>
>> One of the selling point about a simple data model and access language
>> was that there were never issues where a query planner "refused" to
>
> I still think the query language is a good idea but I have one
> negative point about it.
>
> One of the selling point about a simple data model and access language
> was that there were never issues where a query planner "refused" to do
> the query the "optimal way" the user desired. For examp
On Fri, Nov 5, 2010 at 9:44 AM, Eric Evans wrote:
> 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.
>>
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 o
> 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
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 f
