[Fwd: Re: UUID datatype]

Sorry, this was meant to have been sent to the group, not just Kris.

-------- Original Message --------
Subject: Re: [JDBC] UUID datatype
Date: Sun, 17 Feb 2008 13:05:46 +1100
From: Andrew <archa(at)pacific(dot)net(dot)au>
To: Kris Jurka <books(at)ejurka(dot)com>
References: <47B6E776(dot)9030608(at)pacific(dot)net(dot)au>
<Pine(dot)BSO(dot)4(dot)64(dot)0802161048420(dot)25216(at)leary(dot)csoft(dot)net>
<6e6cc3bc0802160806o6e686b15jbea6cc3e7b36ccbd(at)mail(dot)gmail(dot)com>
<Pine(dot)BSO(dot)4(dot)64(dot)0802161113490(dot)495(at)leary(dot)csoft(dot)net>

Hi Kris,

I'm probably telling you what you already know, but in an attempt to
answer your question...

With the java.util.UUID class, it is simply an encapsulation of a 128
bit unsigned integer, with some convenience functions to take and return
a canonical 36 char, 5 segment string representation of this value. The
Leach-Salz variant as used by java.util.UUID (ISO/IEC 11578:1996) is
what is defined in RFC 4122 and ISO/IEC 9834-8:2005 as per the
PostgreSQL UUID datatype, so they both use the Leach-Salz variant for
their UUID interpretations. The variant potentially impacts lexical
ordering, the meaning attached to each field within the 128 bit
structure, and the string representation. But regardless of the
variant, the underlying 128 bit value remains the same across all 128
bit UUID's, hence the reason why a java.util.UUID can support other
variants, but cannot guarantee the correct canonical representation or
correct ordering of those other variants. From a JDBC driver
perspective, the variant should not be a concern, as from its
perspective, it is only concerned with transferring the 128 bit value
between the client and the database, regardless of the meaning attached
to the various internal bit fields by a particular variant.

I'm unclear around the Microsoft space, as there is a Microsoft variant
for backwards compatibility, but .Net and Java can interchange UUID's
and GUID's over web services with no issue that I'm aware of, and I have
not read anything of incompatibility, only that UUID's and GUID's are
synonymous with respect to each other and both comply to the ISO/IEC
11578:1996 standard.

However, Cold Fusion have a proprietary canonical representation of a
UUID as a 35 char, 4 segment string. So using java.util.UUID would
support the majority other than Cold Fusion users, as they will need to
continue applying whatever workarounds that they currently use.

I'm not quite sure what /ntr/ meant by "/java.util.UUID and UUID in PG
they are different things/", because as I have just explained they are
one and the same. The only reason why I initially suggested the driver
map a PG UUID to a new PGuuid class myself was because the JDBC spec
does not currently have a java.util.UUID mapping, so doing so would
deviate from the specification. By creating a PGuuid class and all that
doing so implies such as agreeing to what functionality to wrap around
it, it would then only be accessible by calling the custom API, thus not
causing the spec deviation. But if a spec deviation in this matter is
not seen as an issue, my personal preference is very strongly to have
the driver mapped to a java.util.UUID class.

Apologies for the length of the reply, but I hope it answers your
question satisfactorily.

Andy

Kris Jurka wrote:
>
>
> On Sun, 17 Feb 2008, ntr wrote:
>
>> java.util.UUID and UUID in PG they are different things.
>> it's better to map THAT to a PGuuid class!
>>
>
> Could you be more clear on what the differences are? While the
> java.util.UUID class specifically mentions the Leach-Salz variant, it
> seems like it supports other versions as well.
>
> Kris Jurka
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
>