Here we go again. Why do we invent sortable uuids every single year?
Sortable Collision-Free UUIDs
61–65 of 65 posts
Re: Sortable Collision-Free UUIDs
#62Earlier quoted context omitted.
Is there a reason or need to be UUID compatible? I honestly don't know. I use them in databases and know they're pretty safe to use when integrating data across multiple databases because collisions are astronomically unlikely, if implemented properly.
So here's a real-world use case that having an RFC 4122 UUID was useful for me. I have a server which accepts reports and stores them in S3. For each new report, a v4 UUID is generated that that is used as the base of the S3 object name. This UUID becomes the report ID. An entire system has been built around the report ID, expecting a hex UUID. Recently, I needed to change how the objects are stored in S3 in order to…
The version bits are for the UUID version though, not for your own versioning use. It doesn't sound like your v5 UUID was actually a UUID v5 (with namespace), so are your new UUID's even RFC 4122 compliant anymore?
At this point, you could just use one of these not-a-UUID replacements and include a few versioning bits of your own. Of course, you'd have to plan it in advance, my point is you used a lucky hack, not a feature of UUID's.
Re: Sortable Collision-Free UUIDs
#63I think the issue with a lib like this is that people might use it, thinking they don't need the IDs to be secure... until they need to be. But by then plenty would have been generated, and a lot of code would rely on this sortable property. In fact, I don't see the point of a library like this, it's trying to encode two pieces of information into one string. Why is that? Why not encode geolocation or IP while they'r…
This seems to be one of those things that you can never convince people of. Everyone thinks that their database is going to have so much data in it that having a sortable ID is important for "performance", and that sorting by another field is silly because of "performance".
ID's are there to identify the row. You can sort it by whatever you like, preferably something that makes sense from a user perspective so the users don't get handed lists of stuff in what seems to them to be a stupid order.
Re: Sortable Collision-Free UUIDs
#64Earlier quoted context omitted.
So here's a real-world use case that having an RFC 4122 UUID was useful for me. I have a server which accepts reports and stores them in S3. For each new report, a v4 UUID is generated that that is used as the base of the S3 object name. This UUID becomes the report ID. An entire system has been built around the report ID, expecting a hex UUID. Recently, I needed to change how the objects are stored in S3 in order to…
The version bits are for the UUID version though, not for your own versioning use. It doesn't sound like your v5 UUID was actually a UUID v5 (with namespace), so are your new UUID's even RFC 4122 compliant anymore? At this point, you could just use one of these not-a-UUID replacements and include a few versioning bits of your own. Of course, you'd have to plan it in advance, my point is you used a lucky hack, not a f…
If I hadn't been using RFC 4122 UUIDs, I wouldn't have had any reserved bits to work with. There are a bunch of places in this system that restricted the report ID to be a hex string of length 32 that would have needed updating if I switched to a different format.
There's also no functional difference between a v4 UUID and a v5 UUID with fixed namespace and random bits for the name portion, so I disagree what I'm doing is no longer RFC 4122 compliant.
It's lucky I used RFC 4122 UUIDs in the first place, that I could take advantage of the designers foresight to set aside some extra bits.
Re: Sortable Collision-Free UUIDs
#65Are they sortable as a string or as binary? Once you deploy something like this, that becomes important because you'll end up storing binary and string representations in different spots, unless you're _really_ careful (and DBs can insert way faster if you're always doing so near the end of the primary key sorting). And unless you use a totally custom string function, you can't have both, since base64 has letters bef…
I think if you store as hex, which is the traditional string representation of a UUID, then the string and binary representation will sort identically.
[deleted]