cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roshan Dawrani <>
Subject Re: Converting a TimeUUID to a long (timestamp) and vice-versa
Date Thu, 06 Jan 2011 02:30:45 GMT
Hi Patricio,

Thanks for your comment. Replying inline.

2011/1/5 Patricio Echag├╝e <>

> Roshan, just a comment in your solution. The time returned is not a simple
> long. It also contains some bits indicating the version.

I don't think so. The version bits from the most significant 64 bits of the
UUID are not used in creating timestamp() value. It uses only time_low,
time_mid and time_hi fields of the UUID and not version, as documented here:

When the same timestamp comes back and I call
TimeUUIDUtils.getTimeUUID(tmp), it internally puts the version back in it
and makes it a Time UUID.

> On the other hand, you are assuming that the same machine is processing
> your request and recreating a UUID base on a long you provide. The
> clockseqAndNode id will vary if another machine takes care of the request
> (referring to your use case) .

When I recreate my UUID using the timestamp() value, my requirement is not
to arrive at the exactly same UUID from which timestamp() was derived in the
first place. I need a recreated UUID *that should be equivalent in terms of
its time value* - so that filtering the time-sorted columns using this time
UUID works fine. So, if the lower order 64 bits (clockseq + node) become
different, I don't think it is of any concern because the UUID comparison
first goes by most significant 64 bits, i.e. the time value and that should
settle the time comparison in my use case.

> Is it possible for you to send the UUID to the view? I think that would be
> the correct behavior as a simple long does not contain enough information to
> recreate the original UUID.

In my use case, the non-Java clients will be receiving a number of such
UUIDs then and they will have to sort them chronologically. I wanted to
avoid bits based UUID comparison in these clients. Long timestamp() value is
perfect for such ordering of data elements and I send much lesser amount of
data over the wire.

>  Does it make sense?

Nearly everything makes sense to me :-)

Twitter: @roshandawrani <>
Skype: roshandawrani

View raw message