<div dir="ltr">On Thu, May 30, 2013 at 8:58 AM, Ian Booth <span dir="ltr"><<a href="mailto:ian.booth@canonical.com" target="_blank">ian.booth@canonical.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div>I think we can add a natural key to Machine without introducing any schema<br>
incompatibilities. From a business perspective, we really just want to store the<br>
namespaced nested "path" to the machine. We can retain the current id as the<br>
surrogate key since we never re-used a machine id (if I understand correctly).<br>
And we can provide a mechanism to get the natural key and if empty, just use the<br>
existing id, which is what non-nested machine's natural key values would be.<br></blockquote><div><br></div><div style>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.)</div>
<div><br></div><div style>Given solid agreement that proper PKs are not optional -- they're just not *as* urgent as some other things -- can you live with this? ;)</div><div style><br></div><div style>Cheers</div><div style>
William</div><div><br></div></div></div></div>