Roshan, the first 64 bits does contain the version. The method UUID.timestamp() indeed takes it out before returning. You are right in that point. I based my comment on the UUID spec.
What I am not convinced is that the framework should provide support to create an almost identical UUID where only the timestamp is the same (between the two UUIDs). UUID.equals() and UUID.compareTo() does compare the whole bit set to say that two objects are the same. It does compare the first 64 bits to avoid comparing the rest in case the most significant bits already show a difference. But coming to your point, should Hector provide that kind of support or do you feel that the problem you have is specific to your application ? I feel like UUID is as it says an Unique Identifier and creating a sort-of UUID based on a previous timestamp disregarding the least significant bits is not the right support Hector should expose. Thoughts? On Wed, Jan 5, 2011 at 6:30 PM, Roshan Dawrani <roshandawr...@gmail.com>wrote: > Hi Patricio, > > Thanks for your comment. Replying inline. > > 2011/1/5 Patricio Echagüe <patric...@gmail.com> > > 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: > > http://download.oracle.com/javase/1.5.0/docs/api/java/util/UUID.html#timestamp%28%29. > > > 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 :-) > > -- > Roshan > Blog: http://roshandawrani.wordpress.com/ > Twitter: @roshandawrani <http://twitter.com/roshandawrani> > Skype: roshandawrani > > -- Patricio.-
