4 ms·
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.
by 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 agoexpecting 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 agoMy 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 agomy 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 agoThe 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 agothere 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 agoBut 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.