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.
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!) On Tue, Jun 22, 2010 at 7:04 PM, Tatu Saloranta <tsalora...@gmail.com>wrote: > On Tue, Jun 22, 2010 at 5:58 AM, David Boxenhorn <da...@lookin2.com> > wrote: > > I want to use UUIDs whose alphanumeric order is the same as their > > chronological order. So I'm generating Version 4 UUIDs ( > ... > > Is there anything wrong with this idea? > > If you want to keep it completely ordered, it's probably not enough to > rely on System.currentTimeMillis(). It seems likely that it would > sometimes be called twice for same clock value? This is easy to solve > locally (just use an additional counter, that's what UUID packages do > to get to 100 nanosecond resolution); and it might not matter in > concurrent case (intra-node ordering is arbitrary but close enough). > The other theoretical problem is reduction in random value space, but > 75 bits of randomness may be well is enough. > > -+ Tatu +- >
