4 ms·

This is a really long winded way of describing a few things to be careful about when using UUIDs as primary keys (and mostly due to [ab]using strings and regula

by dcow 5y ago

This is a really long winded way of describing a few things to be careful about when using UUIDs as primary keys (and mostly due to [ab]using strings and regular expressions to handle them). It _doesn't matter_ who generates them, all the points still stand. Mainly: make sure to canonicalize the things when comparing and use a real UUID type. The leap to broadly not recommending “user provided primary keys” feels hyperbolic.

dale_glass 5y ago
It does matter who generates them. UUIDs are generally assumed not to collide, since that's extremely unlikely. But if you allow an user to generate them, then they can try various shenanigans such as generating duplicated IDs, generating IDs that might have some sort of special meaning (eg, all zeroes), generating non-random IDs that could degrade performance, or storing some sort of data inside the ID.
- chrsig 5y ago
  For that matter, they may not even be trying to do so. Depending on generation method, it can be really easy to generate duplicate uuids from two different processes on the same machine that aren't synchronizing with each other. In general, the other party generating your identifiers takes all the control out of your hands, so you have to start safeguarding against malicious/antagonistic/non-compliant inputs. And lose out on optimizing opportunities (e.g., opting to use a generation method that offers partial ordering)
  - dcow 5y ago
    So return a 409 and make the user generate a new one. Again, there’s nothing unique to who generates the UUID in this problem provided you validate the UUID which you should be doing anyway.
    - iudqnolq 5y ago
      You can't tell, given a number, if it was randomly chosen. This could lead to a hash dos for example if you assume your uuid distribution is random.
      - dcow 5y ago
        Use a good hash, then: https://doc.rust-lang.org/std/collections/struct.HashMap.html https://doc.rust-lang.org/std/collections/struct.HashMap.htm....
jfindley 5y ago
Yes, this reads like a user who is dead set against all typing in software and is then surprised when that works out badly. There are some real problems with UUIDs as primary keys but they fail to mention any of them (some examples: UUIDs are quite large, which make them an expensive option for large tables, v1 UUIDs don't work well for distributed databases as the timestamps cause hotspotting, etc etc).

by dcow 5y ago

dale_glass 5y ago

It does matter who generates them. UUIDs are generally assumed not to collide, since that's extremely unlikely. But if you allow an user to generate them, then they can try various shenanigans such as generating duplicated IDs, generating IDs that might have some sort of special meaning (eg, all zeroes), generating non-random IDs that could degrade performance, or storing some sort of data inside the ID.

chrsig 5y ago
For that matter, they may not even be trying to do so. Depending on generation method, it can be really easy to generate duplicate uuids from two different processes on the same machine that aren't synchronizing with each other. In general, the other party generating your identifiers takes all the control out of your hands, so you have to start safeguarding against malicious/antagonistic/non-compliant inputs. And lose out on optimizing opportunities (e.g., opting to use a generation method that offers partial ordering)
- dcow 5y ago
  So return a 409 and make the user generate a new one. Again, there’s nothing unique to who generates the UUID in this problem provided you validate the UUID which you should be doing anyway.
  - iudqnolq 5y ago
    You can't tell, given a number, if it was randomly chosen. This could lead to a hash dos for example if you assume your uuid distribution is random.
    - dcow 5y ago
      Use a good hash, then: https://doc.rust-lang.org/std/collections/struct.HashMap.html https://doc.rust-lang.org/std/collections/struct.HashMap.htm....

jfindley 5y ago

Yes, this reads like a user who is dead set against all typing in software and is then surprised when that works out badly. There are some real problems with UUIDs as primary keys but they fail to mention any of them (some examples: UUIDs are quite large, which make them an expensive option for large tables, v1 UUIDs don't work well for distributed databases as the timestamps cause hotspotting, etc etc).