Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of tsaloranta@gmail.com
 designates 209.85.160.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=jnaCgIw1yE5jHCcUgRehIbm+wR1aYOQjEiF21nR/TyV2gzTSI/3ixFBS8sxBvxrC8Z
         AJK0MDtH/AcYT1hF09Keh6QYSg7SJqk1iJ19iFneyUGHbeOMILF7JbKM0UBaBGz3FF4W
         +gBQ45SvrS2hOkbdLcNPsvZWcXZW+J1vhd48I=
MIME-Version: 1.0
In-Reply-To: <AANLkTinC7AQdUtwS9SAZH5zIutLqCkGMiKAKUUowKYDU@mail.gmail.com>
References: <AANLkTinIvUcdIpMRR4KlltwKcKSLejNLd6qUukQC0Wvs@mail.gmail.com>
	<AANLkTim33Ftk9jOPwYx3H2GosD0cyxXMPRHRTWHi-zeM@mail.gmail.com>
	<AANLkTinC7AQdUtwS9SAZH5zIutLqCkGMiKAKUUowKYDU@mail.gmail.com>
Date: Tue, 22 Jun 2010 12:05:27 -0700
Message-ID: <AANLkTinQAiOMtiKFeuNHxPskInsMYLp15Jh6QrpYC_os@mail.gmail.com>
Subject: Re: UUIDs whose alphanumeric order is the same as their chronological
	order
From: Tatu Saloranta <tsaloranta@gmail.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jun 22, 2010 at 9:12 AM, David Boxenhorn <david@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 +-