[Fwd: Re: [kforge-dev] uuids: are they a good idea]

Mon Nov 7 11:56:29 UTC 2005

I think Nick forgot to cc the list so I'm forwarding this.

-------- Original Message --------
Subject: Re: [kforge-dev] uuids: are they a good idea
Date: Sun, 6 Nov 2005 17:36:17 +0000
From: Nick Stenning <nickstenning+lists at gmail.com>
To: Rufus Pollock <rufus.pollock at okfn.org>
References: <4367BB2A.6080309 at okfn.org>

Although you've probably made this decision, I thought I'd put forward
some points that I've thought about when wondering about this for
another project I'm working on at the moment.

>    * Global uniqueness making it
>       * easier to integrate different projects if that were every necessary
>       * do system upgrades (ids are currently used for directory naming
> on disk)

These I agree with, not least because it's quite hard to disagree with
them, as they're the very problems which GUIDs were designed to solve
=)

> * Increased portability across databases and architectures

This very much depends on implementation. For our project (!= kforge)
we're considering implementing GUIDs as full-blown SQL indexes, but it
strikes me that were you to do it this way, it probably/possibly
*wouldn't* be as portable. TBH I just *don't* know enough about this
one.

>    * slower (?)

Maybe, and again you'd want to do some benchmarks, but someone did
some for us, and the performance hit is orders of magnitude too small
to notice for a web application.

>    * not as reliable as standard integer ids

How so? Doesn't this contradict outright the points you made in favour
of GUIDs?

>    * no built in uuid type (at least in postgresql) and would have to
> find a python implementation

Yes, for portability purposes you probably wouldn't ever put this sort
of thing in DB "logic" ... (yes, I know logic isn't the right word
there, but you know what I mean ;o) ...)

> This is still very much undecided but if we are to make the change it
> would be good to do it before 1.0 so comments on this issue are
> particularly welcome.

Well the one final point we've come across, although I don't know if
it'll affect you, is that sometimes you might want to access a
record/series of records taking parameters from a URI. Personally, I
find /myproj/somerecord/8 much more attractive and usable than
something like:
/myproj/somerecord/C7A64573-A91C-42D0-855D-2021743736EC

=) But then again I'm sure you weren't considering using it like that...

 From the small amount I've seen of the kforge system, I have to
confess I don't know that I see what problems GUIDs are the solution
of. Perhaps I've got the wrong end of the proverbial stick, but
haven't you already got a unique identifier in the form of the project
unix name? But then again, using unix names would result in collisions
if you ever had to merge kforge systems ;o)

I do like GUIDs, and I think they can in certain circumstances be very
useful. We found that they weren't solving a problem for us, so we
didn't use them. Hope my comments can be of some use to you.

Regards,
Nick