Hi Patricio, Some thoughts inline.
2011/1/6 Patricio Echagüe <patric...@gmail.com> > 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. > I know 64 bits have the version, but timestamp() doesn't and hence it is OK to use it for chronological ordering. Anyway, we agree on it now and this point is out. > > 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). > Well, I didn't really ask for framework to provide me such an almost identical UUID. What I raised was that since Hector is computing UTC time in 100 nano-sec units as utcTime = msec * 1000 + 0x01B21DD213814000L (NUM_100NS_INTERVALS_SINCE_UUID_EPOCH), it should, at the minimum, give a utility function to do the opposite msec = (utcTime - 0x01B21DD213814000L / 1000), so that if someone has to create an almost identical UUID, where timestamp is same, as I needed, *he shouldn't need to deal with such magic numbers that are linked to Hector's guts.* So, I don't mind creating the UUID myself, but I don't want to do magic calculations that should be done inside Hector to-and-fro, as it is an Hector's internal design thing. > > 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. > I know it may need to look at all 128 bits eventually - but it first looks at first 64 bits (time stamp) and then the next 64. That's why I qualified it with "for my usecase". It works for me, because the data I am filtering is already within a particular user's data-set - and the possibility of a user having 2 data-points at the same nano-second value (so that clockseq+node bits come into picture) is functionally nil. > > 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 ? > As covered above, half of my solution should go inside Hector API, I feel. Other half about re-creating the same-timestamp-UUID and comparison using it is specific to my 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. > The support Hector should expose is to keep its magic calculations inside to-and-fro. Does it make any sense? -- Roshan Blog: http://roshandawrani.wordpress.com/ Twitter: @roshandawrani <http://twitter.com/roshandawrani> Skype: roshandawrani
