SEO

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()?

Roy

2008/5/9 Roy Hann <specially@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()?
>

I'd suggest taking a look at the source (
http://code.ingres.com/ingres/main/s..._unix/iduuid.c or
http://code.ingres.com/ingres/main/s...d_win/iduuid.c) It's pretty
heavily commented, including at the top:

"** 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.

HTH

--
Paul Mason

2008/5/9 Paul Mason <latepaul@gmail.com>:

>
>
> 2008/5/9 Roy Hann <specially@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()?
>>
>
> I'd suggest taking a look at the source (
> http://code.ingres.com/ingres/main/s..._unix/iduuid.c or
> http://code.ingres.com/ingres/main/s...d_win/iduuid.c) It's pretty
> heavily commented, including at the top:
>

Should've followed my own advice. Reading the source there is a random
element. It also looks like we're following version 1.


--
Paul Mason

"Paul Mason" <latepaul@gmail.com> wrote in message
news:mailman.215.1210358563.2607.info-ingres@kettleriverconsulting.com...

> 2008/5/9 Roy Hann <specially@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):

bb15cc31-fcc9-4c6e-ad21-7349e11f5e14
8f98246f-e393-44e5-9d9c-718838e89f93
70e9e3dc-7f3c-436c-a913-f03279d4f28d
2cd1136c-0e2b-423c-9253-b461d29d7755

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.

>> Is there any sensible interpretation of the output of uuid_to_char()?

> I'd suggest taking a look at the source
> (http://code.ingres.com/ingres/main/s..._unix/iduuid.c or
> http://code.ingres.com/ingres/main/s...d_win/iduuid.c) It's
> pretty heavily commented

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?

Roy

"Roy Hann" <specially@processed.almost.meat> wrote in message
news:-rSdndIaTMcSNLnVnZ2dnUVZ8hidnZ2d@pipex.net...

> 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):
>
> bb15cc31-fcc9-4c6e-ad21-7349e11f5e14
> 8f98246f-e393-44e5-9d9c-718838e89f93
> 70e9e3dc-7f3c-436c-a913-f03279d4f28d
> 2cd1136c-0e2b-423c-9253-b461d29d7755
>
> are Version 4 (because the high-order 4 bits of the so-called
> "time_hi_and_version" field are 0100).

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.:

8a467b18-1e02-11dd-9131-000000000000
8a468972-1e02-11dd-8932-000000000000
8a468c7b-1e02-11dd-ac16-000000000000
8a468f6a-1e02-11dd-a0d6-000000000000

I don't like the dissimilar behaviour. I am inclined to say it is a nasty
mis-feature if not an outright bug.

Roy

On May 9, 2008, at 3:44 PM, Roy Hann wrote:

> "Paul Mason" <latepaul@gmail.com> wrote in message
> news:mailman.215.1210358563.2607.info-
> ingres@kettleriverconsulting.com...
>
>> I'd suggest taking a look at the source
>> (http://code.ingres.com/ingres/main/s..._unix/iduuid.c or
>> http://code.ingres.com/ingres/main/s...d_win/iduuid.c) It's
>> pretty heavily commented
>
> 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.

Karl

2008/5/9 Roy Hann <specially@processed.almost.meat>:

> "Roy Hann" <specially@processed.almost.meat> wrote in message
> news:-rSdndIaTMcSNLnVnZ2dnUVZ8hidnZ2d@pipex.net...
>
> > 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):
> >
> > bb15cc31-fcc9-4c6e-ad21-7349e11f5e14
> > 8f98246f-e393-44e5-9d9c-718838e89f93
> > 70e9e3dc-7f3c-436c-a913-f03279d4f28d
> > 2cd1136c-0e2b-423c-9253-b461d29d7755
> >
> > are Version 4 (because the high-order 4 bits of the so-called
> > "time_hi_and_version" field are 0100).
>
> 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.:
>
> 8a467b18-1e02-11dd-9131-000000000000
> 8a468972-1e02-11dd-8932-000000000000
> 8a468c7b-1e02-11dd-ac16-000000000000
> 8a468f6a-1e02-11dd-a0d6-000000000000
>
> 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.

--
Paul Mason

>"Paul Mason" <latepaul@gmail.com> wrote in message
>news:mailman.219.1210413562.2607.info-ingres@kettleriverconsulting.com...
>
>>> 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.

Roy

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.

Roy

"Gerard Schoorl" <Gerard.Schoorl@psb.nl> wrote in message
news:mailman.221.1210485841.2607.info-ingres@kettleriverconsulting.com...
> 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.

Roy