Why not CUID?
Some details on how CUIDs work: https://github.com/ericelliott/cuid
Understanding UUIDs, ULIDs and string representations
31–40 of 104 posts
Re: Understanding UUIDs, ULIDs and string representations
#32Cockroach DB supports ULID since v21.2.3 using gen_random_ulid().
Re: Understanding UUIDs, ULIDs and string representations
#33Most people are familiar with time and random UUIDs but and I had sort of known about v5 UUIDs but recently used them to get consistent identifiers from an input value… super useful because you can do `uuidv5($namespace_uuid, data)` and get the same UUID everytime.
Isn’t that just a hash?
If you have data-driven tests that compute UUIDs along the way to their results, plopping in an UUID generator that is a predictable hash algo is a good thing.
This is similar to C rand(), which you wouldn't want to use in production but is useful when generating the same test data for the same seed every time.
Re: Understanding UUIDs, ULIDs and string representations
#34We use K-Sortable Globally Unique IDs: https://github.com/segmentio/ksuid
Some differences:
128 bit strongly generated payload (instead of 80 bits for ULIDs).
Only 32 bit time precision but that's wall clock time anyway.
Base62 encoded.
Re: Understanding UUIDs, ULIDs and string representations
#35Author here, self-posted. AMA.
I think Base85 [0] warrants a mention for those needing to minimize the string representation length of their UUIDs.
A year ago or so we had to store a reference to one of our entities into a legacy third-party system, which used char(20) as the column size and of course couldn't be changed.
Since Base85 encodes a UUID as exactly 20 ASCII characters, it saved me from having to add an extra indirection. (Also, and to be honest mainly, from giving ammo to our CEO who had never liked UUIDs)
Of the various 85-character encodings, I thought Z85 [1] was the best one. It's not URL-safe, but it's safe for copy-pasting into queries, source code, XML, JSON, CSV, etc.
Re: Understanding UUIDs, ULIDs and string representations
#36Most people are familiar with time and random UUIDs but and I had sort of known about v5 UUIDs but recently used them to get consistent identifiers from an input value… super useful because you can do `uuidv5($namespace_uuid, data)` and get the same UUID everytime.
Isn’t that just a hash?
It is a hash, but in the format of a UUID. This is useful if you are storing it in the database, since there is usually a dedicated data type for UUIDs. Also, you can mix UUID v4 and v5 IDs freely.
Re: Understanding UUIDs, ULIDs and string representations
#37All this stuff about collisions and avoiding them, even though they will never happen, feels like a PHB compliance issue. “Great work Geoff! One question: what’s the probability of two transactions having the same ID?” “It is very low” “Hmmm. But it’s not zero?” “It’s so low that it practically is zero.” “But it’s not technically zero? This company wasn’t built on taking chances, son! Come back when your product comp…
This is when any tech person worth their salt should lean over and say: "Okay boss, we _could_ do that, but so you know what that would mean?" And then you tell them about cosmic rays, bitflips and redundant computing and what that would mean for the cost of IT at your company. "... or, we could just use UUIDs like nearly everybody else. I will spend a few days thinking about what would happen in case of a UUID colli…
In my experience, saying stuff like "the chance of a UUID collision is about the same as your car being struck by lighting and hit by a meteorite every day for a year" works on some non-STEM people.
But there are a lot more for whom "look, Azure uses UUIDs for their VMs, and it's good enough for them" is somehow more convincing.
Re: Understanding UUIDs, ULIDs and string representations
#38Author here, self-posted. AMA.
I think Base85 [0] warrants a mention for those needing to minimize the string representation length of their UUIDs. A year ago or so we had to store a reference to one of our entities into a legacy third-party system, which used char(20) as the column size and of course couldn't be changed. Since Base85 encodes a UUID as exactly 20 ASCII characters, it saved me from having to add an extra indirection. (Also, and to…
Nice, thanks, haven’t see. This before. Can’t say I like the symbols in there, but will add it as a reference.
Should probably add base58 as well, Bitcoin uses it.
Re: Understanding UUIDs, ULIDs and string representations
#39Author here, self-posted. AMA.
Great write up! Do you know if lex62 has any performance disadvantage versus bases that are in 2^n? (32, 64 etc?) I always assumed the conversation to 2^n bases could be done more efficiently.
Hmm. I haven’t actually gone low level enough to answer that, but I suppose it’s possible - doesn’t seem likely to be significant in a web application server scenario, though. The random jitter on the lan line to the DB is probably going to be more significant.
Re: Understanding UUIDs, ULIDs and string representations
#40First time hearing about ULIDs. The locality is interesting, but they leak information about when they were generated down to the millisecond, which could lead to problems if combined with other issues. I'd be wary of using them client-side.
Can someone expand on the practical consequences with leaking when things were created to the millisecond?
You might want to expose joining dates for example, or exactly when something happened. That kind of info can leak unintentionally if someone looks at the ID and you didn’t want it exposed.