4 ms·

In the real world, the likelihood that a bug in your database engine or ID-hander-outer (a race condition, storage edge case or the like) is a lot higher than t

In the real world, the likelihood that a bug in your database engine or ID-hander-outer (a race condition, storage edge case or the like) is a lot higher than the risk of collision on a sufficiently large and random key. The whole point of using UUIDs is that you can generate them locally without central coordination--if you want to coordinate your identifiers, you can use a much friendlier ID length (which is explained in the article).

kevincox 2y ago
But you still need to be wary of malicious collisions. I have seen security vulnerabilities where the client generates a UUID ID and that was inserted into the database. However by picking an ID that corresponded to objects from other users it was possible to gain some access to those objects. So any UUID coming from an untrusted source (like a client application) should be checked for uniqueness. However your client apps can be written assuming that their randomly generated UUIDs never have collisions.
- echoangle 2y ago
  Why would you let the client generate the IDs? If you have to check them anyways, just generate them on the server and only give the ID to the client.
  - kevincox 2y ago
    It can be very useful for offline work and latency hiding. For example the client can generate data structures with the final IDs then sync them to the server. This can also be useful for implementing idempotent updates. The alternative of having some sort of "placeholder ID" until the sever gets back to you (or you get back online) adds a lot of client complexity.
    - echoangle 2y ago
      Can't you just give the client a list of generated IDs on the first request and check if the IDs are from the pregenerated IDs afterwards? That should be a lot cheaper than checking all IDs you ever generated.
      - kevincox 2y ago
        You can do that I suppose. But I have found that in most cases I have a unique index on the ID anyways, as they are often table primary keys. So really I just have to ensure that it is either an INSERT or an UPDATE to a record that is owned by the user.
        echoangle 2y ago
        Then you don't really have the problem this is about though, and which UUIDs are supposed to solve. The real pro of UUIDs is that you can issue them in distributed situations where you can't look up the already used IDs easily.

kevincox 2y ago

But you still need to be wary of malicious collisions. I have seen security vulnerabilities where the client generates a UUID ID and that was inserted into the database. However by picking an ID that corresponded to objects from other users it was possible to gain some access to those objects. So any UUID coming from an untrusted source (like a client application) should be checked for uniqueness. However your client apps can be written assuming that their randomly generated UUIDs never have collisions.

echoangle 2y ago
Why would you let the client generate the IDs? If you have to check them anyways, just generate them on the server and only give the ID to the client.
- kevincox 2y ago
  It can be very useful for offline work and latency hiding. For example the client can generate data structures with the final IDs then sync them to the server. This can also be useful for implementing idempotent updates. The alternative of having some sort of "placeholder ID" until the sever gets back to you (or you get back online) adds a lot of client complexity.
  - echoangle 2y ago
    Can't you just give the client a list of generated IDs on the first request and check if the IDs are from the pregenerated IDs afterwards? That should be a lot cheaper than checking all IDs you ever generated.
    - kevincox 2y ago
      You can do that I suppose. But I have found that in most cases I have a unique index on the ID anyways, as they are often table primary keys. So really I just have to ensure that it is either an INSERT or an UPDATE to a record that is owned by the user.
      - echoangle 2y ago
        Then you don't really have the problem this is about though, and which UUIDs are supposed to solve. The real pro of UUIDs is that you can issue them in distributed situations where you can't look up the already used IDs easily.