Hacker News Reader

Comment by afiori | Hacker News Reader

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.

View on HN

My guess is that Iin 99% collision could occur during insert. Most of the time db will just not allow to insert duplicated record.

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.

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.

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).

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.

Reply on news.ycombinator.com