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

[John Bywater]

Thanks Nick. I don't think a decision has been made, but I'm steeply 
inclined not to use them.

I think your consideration is a nice summary of the concerns.

(BTW The project unixname isn't globally unique. It's just as unique as 
the integer id.)

It seems to be hoped that uids would solve the problem of data 
migration. But data migration isn't entirely solved by adopting uids.

At the same time, messing with the workings of the RDBMS isn't wise. I'm 
against messing around with the internals of third party subsystems, and 
especially one that has been maturing for decades. I feel strongly that 
we should let the RDBMS manage it's own records, and if it's possible 
(which it is with SQLObject) use a third party ActiveRecord to wrap the 
SQL interface. That just leaves us with responsibility for mapping the 
records into domain objects, and back (which is what kforge.db does with 
its Mapper class). I agree in thinking that we do not have any 
requirement to disturb the workings of the underlying RDBMS subsystem.

Rather than undermining this sub-system, engaging in speculative 
(probably superficial) benchmarking, and worrying about having 
compromised portability, it would be much better to put all of that 
energy into a data migration feature, which is the real concern 
motivating this consideration of uids.

But overall, I don't think there is a business requirement that leads to 
the technical requirement for uids.

But I do think we have a business requirement for data migration: 
exporting, importing, and upgrading.

That having been said, if KForge was expected to be installed as a 
distributed system, where all entities should be unique, then it would 
probably lead to using uids, because relying on a central id service 
probably wouldn't be reliable enough.

So, if KForge services are to be independent of each other, and if 
projects "move house" then they get a new "address", then we don't have 
any need for uids. But if they are supposed to form some kind of 
distributed system, then we would. However, as network reliability 
increases, and as web services are used more, a distributed KForge would 
be created from independent services by layering a directory service 
over the top. But that wouldn't be peer to peer.

A peer to peer KForge would need uids. But we could add that later, and 
migrate data up to having uids.

So, in summary, I'd say we shouldn't entirely forget about uids on 
KForge. But we should forget about them, at least, for the moment.

Best regards,

John.



Rufus Pollock wrote:

> 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
>
> _______________________________________________
> kforge-dev mailing list
> kforge-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/kforge-dev
>
>
>