5 ms·
There’s already a 72-bit random part. That should be sufficient to address conflicts. Incrementing a sequence completely kills the purpose of a UUID, and requi
by sedatk 2y ago
There’s already a 72-bit random part. That should be sufficient to address conflicts.
Incrementing a sequence completely kills the purpose of a UUID, and requires serialization/synchronization semantics. If you need that, just use a long integer.
- n42 2y agoWhat do you consider the purpose of a UUID?
- sedatk 2y agoAsynchronous unique ID generation.
- HexDecOctBin 2y agoYou can have both asynchrony and sequence by encoding thread ID in the UUID too, and make the sequence a thread local state.
- maxbond 2y agoMongoDB uses a similar approach. https://www.mongodb.com/docs/manual/reference/method/ObjectId/ https://www.mongodb.com/docs/manual/reference/method/ObjectI...
- sedatk 2y agoThen, just use thread ID and integer sequence pairs instead of trying to stuff them into an arbitrary binary format.
- HexDecOctBin 2y agoThread IDs get repeated across reboots. Integer sequence may also repeat in a distributed scenario, unless you want a massive bottleneck. You do need other stuff (timestamps, random number, etc.).
- sedatk 2y agoYes, but that’s what parent proposed? :shrug:
- Retr0id 2y agoIf you have a billion users and they each generate 64 random 72-bit numbers, you have a ~63% chance of a collision.
- cowsandmilk 2y agoIf they all did that in the same millisecond?
- wood_spirit 2y agoThere is utility in knowing that event a comes before event b in the same local system even if both are generated at the same millisecond. I have found this useful eg when ui latency gets so low that you can have a user interaction and a menu opening in the same millisecond. Being able to plot them on a timeline without any kind of joins is nice. Anyway, as I said, it was dropped from the spec