4 ms·
I am a big fan of the new uuid v7 format. It has the advantage of being a drop in replacement most places everyone uses v4 today. It also has the advantage ove
by wood_spirit 2y ago
I am a big fan of the new uuid v7 format.
It has the advantage of being a drop in replacement most places everyone uses v4 today. It also has the advantage over other specs of ulid in that it can be parsed easily even in languages and databases with no libraries because you just need some obvious substr replace and from_hex to extract the timestamp. Other specs typically used some custom lexically sortable base64 or something that always needed a library.
Early drafts of the spec included a few bits to increment if there were local ids generated in the same millisecond for sequencing. This was a good fit for lots of use cases like using the new ids for events generated in normal client apps. Even though it didn’t make the final spec I think it worth implementing as it doesn’t break compatibility
- sedatk 2y agoThere’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