4 ms·

Do you write logic to handle collisions?

spullara 5y ago
"A collision is possible but the total number of unique keys generated is so large that the possibility of a collision is almost zero. As per Wikipedia, the number of UUIDs generated to have atleast 1 collision is 2.71 quintillion. This is equivalent to generating around 1 billion UUIDs per second for about 85 years."
- fwip 5y ago
  For clarification, that's the number of UUIDs at which you have a 50% chance of at least one collision. Wikipedia also adds: "the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion."
williamdclt 5y ago
part of the point of UUIDs is that you don't have to. Collision is unlikely enough that your time would be more wisely spent worrying about the sun exploding unless you generate an absolutely absurd amount of data.
Ginden 5y ago
Unless you are writing nuclear warhead management system, writing UUID collision handling is waste of time. Client can retry on top level if request failed.
- afiori 5y ago
  expecting collision to happen is probably a waste of time, but it still sounds like a good idea to bound how much damage a collision might cause.
  - AlfeG 5y ago
    My guess is that Iin 99% collision could occur during insert. Most of the time db will just not allow to insert duplicated record.
    - afiori 5y ago
      my worries were more about access control, it is sort of fine if a costumer experiences data loss because an insert fails and the application doesn't retry, it is less fine if a collision causes a user's documents to be swapped with another user's docoment and they end up showing kinky porn on a live press conference. Sort of the distinction between unspecified behaviour and undefined behaviour in C.
      - nextaccountic 5y ago
        The application shouldn't report the insert as successful if it actually failed. That way, the user don't go around thinking the insert actually succeeded, and there is no data loss (if it didn't succeed it must be retried, by the app or manually) You need some UX like an error message in a red rectangle or something.
        afiori 5y ago
        there would be data loss if the insert/update would meet a collision and either decided to overwrite the record or to report the operation as already completed (the latter is what I imagine git would do for a collision scenario). the solution might as well just be not to care about this case (no sarcasm).
        nextaccountic 5y ago
        But if we're talking about a database insert and there's a collision (and the uuid column has an unique constraint - as it should, since it's meant to be a primary key), then the insert will not be successful. Your application might not care about treating this error, but the DB will report it.

"A collision is possible but the total number of unique keys generated is so large that the possibility of a collision is almost zero. As per Wikipedia, the number of UUIDs generated to have atleast 1 collision is 2.71 quintillion. This is equivalent to generating around 1 billion UUIDs per second for about 85 years."

fwip 5y ago
For clarification, that's the number of UUIDs at which you have a 50% chance of at least one collision. Wikipedia also adds: "the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion."

williamdclt 5y ago

part of the point of UUIDs is that you don't have to. Collision is unlikely enough that your time would be more wisely spent worrying about the sun exploding unless you generate an absolutely absurd amount of data.

Ginden 5y ago

Unless you are writing nuclear warhead management system, writing UUID collision handling is waste of time. Client can retry on top level if request failed.

afiori 5y ago
expecting collision to happen is probably a waste of time, but it still sounds like a good idea to bound how much damage a collision might cause.
- AlfeG 5y ago
  My guess is that Iin 99% collision could occur during insert. Most of the time db will just not allow to insert duplicated record.
  - afiori 5y ago
    my worries were more about access control, it is sort of fine if a costumer experiences data loss because an insert fails and the application doesn't retry, it is less fine if a collision causes a user's documents to be swapped with another user's docoment and they end up showing kinky porn on a live press conference. Sort of the distinction between unspecified behaviour and undefined behaviour in C.
    - nextaccountic 5y ago
      The application shouldn't report the insert as successful if it actually failed. That way, the user don't go around thinking the insert actually succeeded, and there is no data loss (if it didn't succeed it must be retried, by the app or manually) You need some UX like an error message in a red rectangle or something.
      - afiori 5y ago
        there would be data loss if the insert/update would meet a collision and either decided to overwrite the record or to report the operation as already completed (the latter is what I imagine git would do for a collision scenario). the solution might as well just be not to care about this case (no sarcasm).
        nextaccountic 5y ago
        But if we're talking about a database insert and there's a collision (and the uuid column has an unique constraint - as it should, since it's meant to be a primary key), then the insert will not be successful. Your application might not care about treating this error, but the DB will report it.