[Fwd: Re: UUID datatype]
От | Andrew |
---|---|
Тема | [Fwd: Re: UUID datatype] |
Дата | |
Msg-id | 47B7970C.6050001@pacific.net.au обсуждение исходный текст |
Список | pgsql-jdbc |
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@pacific.net.au> To: Kris Jurka <books@ejurka.com> References: <47B6E776.9030608@pacific.net.au> <Pine.BSO.4.64.0802161048420.25216@leary.csoft.net> <6e6cc3bc0802160806o6e686b15jbea6cc3e7b36ccbd@mail.gmail.com> <Pine.BSO.4.64.0802161113490.495@leary.csoft.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 > >
В списке pgsql-jdbc по дате отправления: