News for hackers. Stuff that matters.

A comment on Be Careful with UUID or GUID as Primary Keys.

Re:Be Careful with UUID or GUID as Primary Keys by ivan_gammel on Friday June 09, 2017 @03:33PM (#14523815)
The strategy "internal int-external uuid" can be simplified if you use encryption and hypermedia API. It's possible to encrypt int and some additional information and format it as uuid v4 (random). For external users that know natural keys of some objects it's possible then to discover the rest of objects by navigation via API, where UUIDs are just some pseudo-random parts of the URIs.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by accnt on Friday June 09, 2017 @05:31PM (#14524753)
I was wondering a similar implementation. I encrypt/decrypt database IDs to opaque them on the API. For primary entities but not enums/etc. I separated API vs Core/Database so I wasn't too fond of adapting the entities to add a sort-of public id column so I create it at run-time.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by ivan_gammel on Saturday June 10, 2017 @03:55AM (#14526538)
I can share my code on Github, it will be interesting to find some commons. Probably, this approach deserves more attention.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by MichaelGG on Friday June 09, 2017 @03:39PM (#14523851)
Why would you format it as a UUIDv4 instead of just leaving all bits intact?
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by imhoguy on Friday June 09, 2017 @04:07PM (#14524085)
To take advantage of native UUID support in a database, e.g. PostgreSQL stores them in 128 bits. Also every UUID carries version number so minimal formating needs to be performed to comply with the standard.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by MichaelGG on Friday June 09, 2017 @04:24PM (#14524233)
So you're saying Postgres actually wastes cycles verifying the version information and doesn't treat UUID just as a 16 byte opaque structure?
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by anarazel on Friday June 09, 2017 @04:50PM (#14524443)
Well, there's the "input format" (or rather two), which gets parsed into the internal representation. The input format can be either hex text, which allows dashes in some positions, or binary, in which it's just a bytearray. There's no verification otherwise, unless you treat generation of UUIDs, which allows to specify the type, as such.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by anarazel on Friday June 09, 2017 @06:37PM (#14525112)
Second point: Verifying version information would hardly matter cyclewise.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by nvivo on Friday June 09, 2017 @04:23PM (#14524230)
I'm not sure what you mean exactly. The textual representation of an UUID HAS all the bits intact. UUID formatting is not lossy compression.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by MichaelGG on Friday June 09, 2017 @04:25PM (#14524242)
UUID v4 "spec" leaves 122 bits for randomness and has 6 fixed bits for "version" information. I'm suggesting that following the spec on such stuff is a total waste and serves no point, and you're better off with a random 128-bit number.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by nvivo on Friday June 09, 2017 @06:41PM (#14525126)
Well, then it's not an UUID. It's just 128 random bits. If you just want to be the most random possible, you can go 256, 512, 1024, etc. That may be what you want, but you can't say UUID v4 is a "total waste" or "serves no point".

It's purpose is to never collide with another UUID v4, not to be the most unique value ever.

[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by MichaelGG on Friday June 09, 2017 @09:00PM (#14525641)
UUIDv4 is a 122 bit random number. Having another 6 random bits won't make them collide.

Also if there's UUIDs in your system colliding with a 128 bit random numbers then the rng is broken or your UUID generator would be great to crack encryption keys.

[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by ivan_gammel on Friday June 09, 2017 @03:55PM (#14523992)
Well, that's possible, but I'd say it's generally better to keep close to the spec and v4 is the closest option here.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by MichaelGG on Friday June 09, 2017 @03:59PM (#14524026)
But what's the value in the "spec" here? I see people mentioning this and I'm wondering what the rationale is.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by cronjobber on Saturday June 10, 2017 @02:58AM (#14526433)
The rationale is that you can use them along with those other versions of UUID that contain nonrandom data.

Assume Bob uses one such not-entirely-random UUID variety and actually makes use of the embedded information. Charlie uses random UUID. Bob and Charlie merge their data.

If Charlie had filled the version bits with random garbage, the merge would poison Bob's use of the embedded information.

Basically, UUIDs are a discriminated union type.

[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by ivan_gammel on Saturday June 10, 2017 @03:57AM (#14526540)
Thanks, that's the best answer.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by concede_pluto on Saturday June 10, 2017 @10:26PM (#14530299)
By violating the spec you're assuming you'll never want to use a tool that strictly adheres to the spec. Postel's Law works best because it accommodates some people not following it.
[ Parent | on HN ]