I am looking at using uuid_create() to generate UUIDs. The SQL Reference Manual talks about the internal structure of the UUIDs generated but I am extremely unclear about whether the value actually returned can be parsed as described. I do know UUIDs come in different "versions", including hashed and randomized.
What version is Ingres going to give me? Is there any sensible interpretation of the output of uuid_to_char()?
2008/5/9 Roy Hann <specia...@processed.almost.meat>:
> I am looking at using uuid_create() to generate UUIDs. The SQL Reference > Manual talks about the internal structure of the UUIDs generated but I am > extremely unclear about whether the value actually returned can be parsed > as > described.
They can, though I'm not sure why you'd want to. I have come across a couple of bugs in early 2.6 days with UUIDs, however since they were fixed (may 2005) the format is as described.
> I do know UUIDs come in different "versions", including hashed > and randomized.
> What version is Ingres going to give me?
Not sure about that. The only "random" element is based on the timestamp.
> Is there any sensible > interpretation of the output of uuid_to_char()?
"** Generate a Universally Unique ID (UUID) based on the ** Internet-Draft by Paul J. Leach (Microsoft) and Rich Salz ** (Certco) of the Internet Engineering Task Force (IETF) ** and dated 4-feb-1998."
As each element is generated it's accompanied by a relevant quote from the document describing what it should be.
> 2008/5/9 Roy Hann <specia...@processed.almost.meat>:
>> I am looking at using uuid_create() to generate UUIDs. The SQL Reference >> Manual talks about the internal structure of the UUIDs generated but I am >> extremely unclear about whether the value actually returned can be parsed >> as >> described.
> They can, though I'm not sure why you'd want to. I have come across a > couple of bugs in early 2.6 days with UUIDs, however since they were fixed > (may 2005) the format is as described.
>> I do know UUIDs come in different "versions", including hashed >> and randomized.
>> What version is Ingres going to give me?
> Not sure about that. The only "random" element is based on the timestamp.
>> Is there any sensible >> interpretation of the output of uuid_to_char()?
> 2008/5/9 Roy Hann <specia...@processed.almost.meat>:
>> I am looking at using uuid_create() to generate UUIDs. The SQL >> Reference Manual talks about the internal structure of the UUIDs >> generated but I am extremely unclear about whether the value actually >> returned can be parsed as described.
> They can, though I'm not sure why you'd want to.
I was hoping to sort on the time stamp components to recover the order in which a set of rows were originally created.
> I have come across a > couple of bugs in early 2.6 days with UUIDs, however since they were > fixed (may 2005) the format is as described.
>> I do know UUIDs come in different "versions", including hashed and >> randomized.
>> What version is Ingres going to give me? > Not sure about that. The only "random" element is based on the > timestamp.
Since I posted this question a careful reading of http://www.ietf.org/rfc/rfc4122.txt tells me that UUIDs returned by uuid_to_char() that look like these below, generated using II 9.1.0 (int.w32/119):
are Version 4 (because the high-order 4 bits of the so-called "time_hi_and_version" field are 0100).
If these are version 4 UUIDs then every other bit is supposed to be randomly generated (per the RFC document) and are nothing to do with timestamps or node names or anything else that the SQL Reference Manual documents. Clearly the values above are all over the place--most obviously the node part is definitely not constant.
I did. The id_win version is pretty much commented out. But even more mysteriously, the id_unix version does all kinds of whirling and clanking to produce a UUID based on time and node, and sets the version number using
#ifdef BYTE_SWAP version = 0x1000; #else version = 0x0010;
neither of which is 4. So I wonder, is the source we see the source for what we're executing?
> Since I posted this question a careful reading of > http://www.ietf.org/rfc/rfc4122.txt tells me that UUIDs returned by > uuid_to_char() that look like these below, generated using II 9.1.0 > (int.w32/119):
> I did. The id_win version is pretty much commented out.
Apparently because it calls Winders functions instead.
It would seem that cl/hdr/hdr_win/idcl.h defines IDuuid_create to be the (windows) UuidCreate function, and IDuuid_create_seq is mapped to UuidCreateSequential.
This leaves me no wiser than I was 10 minutes ago, but maybe this means something to someone else.
> > Since I posted this question a careful reading of > > http://www.ietf.org/rfc/rfc4122.txt tells me that UUIDs returned by > > uuid_to_char() that look like these below, generated using II 9.1.0 > > (int.w32/119):
>>> I just got access to my Sun system again, and I see that Ingres II 9.1.0 >>> (su9.us5/119) produces Version 1 UUIDs, as documented! E.g.:
>> I don't like the dissimilar behaviour. I am inclined to say it is a >> nasty >> mis-feature if not an outright bug.
>I'd certainly call it a bug.
I certainly won't argue about that.
I do understand the problems that the various different versions of UUID are supposed to solve, and each version has its uses. That is presumably why they are thought of as different versions of the same thing rather than successive replacements of a defective solution.
In the short term I want the behaviour of Version 1 UUIDs, so reverting to the Unix code for Windows would suit me fine. On the other hand it was probably changed for a reason, so maybe that's a bigger problem than it sounds.
In the long term maybe Ingres needs to support all the versions. Who knows? Personally, at the moment I don't care about anything except Version 1. But whatever happens, the behaviour obviously needs to be consistent across platforms.
Ingres supports time-based UUIDs on all platforms. However, on windows, the default is random UUIDs. This can be changed to time-based UUIDs by setting II_UUID_MAC=TRUE using ingsetenv. On older Ingres versions (e.g. 2.6) you might need a patch to support this.
Gerard
>>> I just got access to my Sun system again, and I see that Ingres II 9.1.0 >>> (su9.us5/119) produces Version 1 UUIDs, as documented! E.g.:
>> I don't like the dissimilar behaviour. I am inclined to say it is a >> nasty >> mis-feature if not an outright bug.
>I'd certainly call it a bug.
I certainly won't argue about that.
I do understand the problems that the various different versions of UUID are supposed to solve, and each version has its uses. That is presumably why they are thought of as different versions of the same thing rather than successive replacements of a defective solution.
In the short term I want the behaviour of Version 1 UUIDs, so reverting to the Unix code for Windows would suit me fine. On the other hand it was probably changed for a reason, so maybe that's a bigger problem than it sounds.
In the long term maybe Ingres needs to support all the versions. Who knows? Personally, at the moment I don't care about anything except Version 1. But whatever happens, the behaviour obviously needs to be consistent across platforms.
> Ingres supports time-based UUIDs on all platforms. > However, on windows, the default is random UUIDs. > This can be changed to time-based UUIDs by setting II_UUID_MAC=TRUE > using ingsetenv. > On older Ingres versions (e.g. 2.6) you might need a patch to support > this.
Aha! Many thanks Gerard.
It's still wrong that the two platforms are different by default but that's an easy fix.
