opaque ids vs. natural keys

[William Reade]

On Thu, May 30, 2013 at 8:58 AM, Ian Booth <ian.booth at canonical.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I think we can add a natural key to Machine without introducing any schema
> incompatibilities. From a business perspective, we really just want to
> store the
> namespaced nested "path" to the machine. We can retain the current id as
> the
> surrogate key since we never re-used a machine id (if I understand
> correctly).
> And we can provide a mechanism to get the natural key and if empty, just
> use the
> existing id, which is what non-nested machine's natural key values would
> be.
>

But then we have a primary key with the wrong data type, delivering very
little value, *alongside* the natural key which is kinda nasty but
consistent with service and unit. I'd rather recast what we have as the
natural key and introduce properly opaque keys all together in one fell
swoop. (Also: if we try to use the existing one as a PK right now, we'll
burn through those top-level ids faster than we allocate top-level
machines, which'll look a bit icky: I'd rather present a 1, 2, 3, 4
sequence of top-level machines than a 1, 3, 17, 19 sequence; and I'd rather
not spend code to fix that up when we can just write the code to present
nice natural keys now, and keep the opaque ids properly opaque when we add
them, without needing to mess with the generation of natural keys.)

Given solid agreement that proper PKs are not optional -- they're just not
*as* urgent as some other things -- can you live with this? ;)

Cheers
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20130530/bb61563c/attachment.html>