On Tue, Jun 22, 2010 at 9:12 AM, David Boxenhorn <da...@lookin2.com> wrote: > A little bit of time fuzziness on the order of a few milliseconds is fine > with me. This is user-generated data, so it only has to be time-ordered at > the level that a user can perceive.
Ok, so mostly ordered. :-) > I have no worries about my solution working - I'm sure it will work. I just > wonder if TimeUUIDType isn't superior for some reason that I don't know > about. (TimeUUIDType seems so bad in so many ways that I wonder why anyone > uses it. There must be some reason!) I think that rationally thinking random-number based UUID is the best, provided one has a good random number generator. But there is something intuitive about rather using location + time-based alternative, based on tiny chance of collision that any (pseudo) random number based system has. So it just seems intuitive safer to use time-uuids, I think -- it isn't, it just feels that way. :-) Secondary reason is probably the ordering, and desire to stay standards compliant. As to ordering, if you wanted to use time-uuids, comparators that do give time-based ordering are trivial, and no slower than lexical sorting. Java Uuid Generator (2.0) defaults to such comparator, as I agree that this makes more sense than whatever sorting you would otherwise get. It is unfortunate that clock chunks are ordered in weird way by uuid specification; there is no reason it couldn't have been made "right way" so that hex representation would sort nicely. -+ Tatu +-
