Please, do not use b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, I checked my database and I was using it already.
Ask HN: We just had an actual UUID v4 collision...
11–20 of 369 posts
Re: Ask HN: We just had an actual UUID v4 collision...
#12Just a stupid question, but why not append the date, even in seconds as hex. It's just a few bytes and would guarantee that everything OK now will be OK in the future?
You can just use a different UUID variant which includes timestamp data instead (e.g. v1 or v7), there are also variants which include the MAC address.
Re: Ask HN: We just had an actual UUID v4 collision...
#13Just a stupid question, but why not append the date, even in seconds as hex. It's just a few bytes and would guarantee that everything OK now will be OK in the future?
yeah, any sort of additional semi-random data could've helped prevent this, I'm sure. That, however, is also kind of the idea of UUIDv4, it has lots of randomness and time built in already.
UUID v4 consists of only random bits, no timestamp info.
Re: Ask HN: We just had an actual UUID v4 collision...
#14The chance of a UUIDv4 collision is very low, but it is never zero. If everything is done properly, then this is very likely the one and only time anyone involved in the telling or reading of this account will ever experience this.
Classic gamblers fallacy!
Re: Ask HN: We just had an actual UUID v4 collision...
#15Please, do not use b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, I checked my database and I was using it already.
I knew it, we're all getting the same cheap UUIDs and the good ones are reserved for the big dogs.
Re: Ask HN: We just had an actual UUID v4 collision...
#16Earlier quoted context omitted.
yeah, any sort of additional semi-random data could've helped prevent this, I'm sure. That, however, is also kind of the idea of UUIDv4, it has lots of randomness and time built in already.
UUID v4 consists of only random bits, no timestamp info.
oh, interesting, I didn't know that and this could possibly be part of the problem perhaps depending on what's used as the seed.
Re: Ask HN: We just had an actual UUID v4 collision...
#17Would the UUID v7 be more collision proof? Hard to say because it takes time into account but then the number of entropy bits are reduced hence the UUID generated exactly at the same time have more chance of a collusion because number of entropy bits are a much smaller space hence could result in collusions more easily. Thoughts?
You open up every millisecond a new block. Should be even more unlikely
Re: Ask HN: We just had an actual UUID v4 collision...
#18I fully agree. It makes no sense. Yet... The only guesses I'm having is that we originally generated UUIDv4s on a user's phone before sending it to the database, and the UUID generated this morning that collided was created on an Ubuntu server. I don't fully know how UUIDv4s are generated and what (if anything) about the machine it's being generated on is part of the algorithm, but that's really the only change I can…
You let users generate a UUID?
To be honest, the chance that you are doing something weird is probably higher than you experiencing a real UUID conflict.
How did your database 'flag' that conflict?
Re: Ask HN: We just had an actual UUID v4 collision...
#19Just a stupid question, but why not append the date, even in seconds as hex. It's just a few bytes and would guarantee that everything OK now will be OK in the future?
> but why not append the date
And use uuid v5 to hash it :)
Re: Ask HN: We just had an actual UUID v4 collision...
#20Please, do not use b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, I checked my database and I was using it already.
I knew it, we're all getting the same cheap UUIDs and the good ones are reserved for the big dogs.
uuid.uuidv4() recently switched to "adaptive entropy" instead of "xmax entropy" in an effort to save costs on non-premium users.