On Tue, Jun 22, 2010 at 11:54 PM, David Boxenhorn <da...@lookin2.com> wrote: > Having a physical location encoded in the UUID *increases* the chance of a > collision, because it means fewer random bits. There definitely will be more > than one UUID created in the same clock unit on the same machine! The same > bits that you use to encode your few servers can be used for over 100 > trillion random numbers!
You did not read what I wrote... I did not say it does, just that people feel as if it does. > > "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." > > "No slower" isn't a good reason to use it! I am willing to take a > (reasonable) time *penalty* to use lexically ordered UUIDs that will work > both in Cassandra and Oracle (and which are human-readable - always good for > debugging)! Huh? These are plain old UUIDs, as readable (or not) as any. Comparator refers to java.util.Comparator (or Comparable for class itself). But fear not, I am not trying to change your mind, just pointing out that there is nothing magical about getting things to sort. Just that sorting by standard String representation is not the only collation order there is. > > I am also willing to take a reasonable penalty to avoid using weird > third-party code for generating UUIDs in the first place. To each his own -- lots of people use "weird" code, and generally use little bit less derogatory and patronizing terms when referring such libraries. And it seems to me that you are perfectly happy writing your own "unweird" code to generate them instead. :-) -+ Tatu +-
