Yes 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.
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.
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'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
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.
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.
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.