They should make the versions UUIDs instead of integers so that we don’t make assumptions about their ordinal relationships.
Or maybe an abbreviated hash of the text of their specifications?
Yea, should have been
V-00000000-0000-0000-0000-000000000008insteadYes and no. They had to put the version identifier somewhere to avoid sorting problems or parsing problems, so I think that putting somewhat in the middle is a good tradeoff.
Reject UUID embrace ULID.
Interesting 👀 https://github.com/ulid/spec
At the company I work at we use UUIDv7 but base63 encoded I believe. This gives you fairly short ids (16 chars iirc, it includes lowercase letters) that are also sortable.
base63? I’d guess you’d mean base64?
Anyways, doesn’t that fuck with performance?
I’m using this in production: RT.Comb - That still generates GUIDs, but generates them sequential over time. Gives you both the benefits of sequential ids, and also the benefits of sequential keys. I haven’t had any issues or collisions with that
It’s Base62 actually, misremembered that. It’s to avoid some special characters iirc. And no, performance is fine.
We’re using this: https://github.com/TheArchitectDev/Architect.Identities
I prefer CUID
Just to clarify: Yes, I do know not all use cases are appropriate for CUID. But in general when generating ID, I’d use CUID2
I didn’t even know it was an ietf standard. Let aline there were versions. Apparently it’s only since may this year that there are 8 versions. Before it were only 5.
There is an IETF standard for UUIDs? Do we need an IETF standard for UUIDs? I’ve been coding since the '90s and never thought a UUID to be complicated or contentious enough to need a standard. I guess it makes for a pretty unique icebreaker to say you’ve contributed to an IETF standard, if you get invited to those sort of parties.
