You must log in or register to comment.
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.
A lot of people in this thread who don’t fully understand how UUIDs work…
You’re not kidding.
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.
Reject UUID embrace ULID.
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.
I’ll be borrowing that little trick
https://github.com/TheArchitectDev/Architect.Identities
Here’s the package one of our former developers created. It has some advantages and some drawbacks, but overall it’s been quite a treat to work with!
Interesting 👀 https://github.com/ulid/spec
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 vote for nanoid.
Personally, I always regarded UUID as one of those overcomplicated and frankly unneded “enterprisey” standards (similar to SOAP and XSD, XSLT and various other XML techonologies). After reading this article my opinion didn’t change.
Also… do they even know what “version” means? That they choose that word over “type” or any other alternative says it all.
UUID Version 7 (v7) is generated from a timestamp and random data.
Use v7 if you’re using the ID in a context where you want to be able to sort. For example, consider using v7 if you are using UUIDs as database keys.
Please, do NOT rely on that and just add to your tables a field with the actual timestamp.
You don’t quite understand. One of the major drawbacks of UUIDs over monotonically increasing id’s is the lack of ability to sort them. Not just for manual querying, but for index operations, caching, data locality etc.
It’s very handy and is a big part of the reason why Twitter developed Snowflake IDs, which are basically like UUIDs v6 and v7.
The UUIDs specs are quite easy to understand and definitely not “enterprisey”.
They chose “version” because they are just that, versions. Improvements over the original design that benefit from new insights and technological improvements. We’re lucky they had the foresight to include a version number in the spec.
They chose “version” because they are just that, versions. Improvements over the original design that benefit from new insights and technological improvements. We’re lucky they had the foresight to include a version number in the spec.
No they aren’t. A higher version of UUID isn’t “newer and better”, like the word “version” implies. It’s just different. It’s like they called a car “vehicle version 1” and a motorbike “vehicle version 2”. The common use of “version” in the software world would mean that a motorbike is a newer and hopefully improved version of a car, which is not the case.
The talking pumpkin is 100% right that they should have used “type” or “mode” or “scheme” or something instead.
“Version” is definitely used commonly to describe two different … versions of the same thing, without implying that one is better than the other or supercedes it. There are two versions of the PS5, one with and one without a disk drive. There are many different versions of Windows, like Home or Enterprise. You can get hardcover or paperback versions of many books. Etc. Etc.
In normal English, when not using a number, sure! But in software, with numbers versions it almost universally means chronological releases of something.
There are many different versions of Windows, like Home or Enterprise. You can get hardcover or paperback versions of many books.
Great examples! Those are both called “editions”, not versions. Thanks for proving my point 😄
Version 5 of a software, device, vehicle or such isn’t necessarily better than version 4, and no official definition of the word “version” require this, either. If I may make another anology: You may pick one of 5 different versions of an outfit to wear, and even though they were labeled in the order they were made, from 1 to 5, none are inherently, objectively better than any other. In the case of UUIDs there are versions that are meant to supercede others, but also simply alternatives for different use-cases. Anyone with access to some up-to-date information can learn what each version’s purpose is.
Version 5 of a software, device, vehicle or such isn’t necessarily better than version 4
Yep, I can attest to that! I used to play Minesweeper Adventure version. Then Microsoft decided to do a complete rewrite and literally ruined the game. It was way slower and way buggier, and on top of that they also lost all my progress. So, well done Microsoft - now instead of seeing more ads (which was undoubtedly why they did the rewrite) I now don’t see ANY ads (because the game is just horrible now and not worth playing anymore, even if it didn’t have any ads!).
He’s not suggesting to replace timestamps (nor database sequences). They’re unique identifiers, and they happen to include a timestamp.
Uhum, why not?
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.
If you’re generating UUIDs from different languages, libraries, etc. you want to be sure there doing it the same way.
My face, screaming in horror, but in words instead. I’ve only really worked with projects in homogenous languages on the application side, so hadn’t considered that. Thanks for taking the time to reply.
Look the issues with java.util.UUID and Postgres.
