5 ms·
TLDR they present 3 new versions that each have their own trade-offs, but are also taking into account being able to use these as DB primary keys, which is real
by atonse 5y ago
TLDR they present 3 new versions that each have their own trade-offs, but are also taking into account being able to use these as DB primary keys, which is really great.
Another thing I was quite curious about (looks like you can use them in existing DB columns etc):
> The UUID length of 16 octets (128 bits) remains unchanged. The
textual representation of a UUID consisting of 36 hexadecimal and
dash characters in the format 8-4-4-4-12 remains unchanged for human
readability. In addition the position of both the Version and
Variant bits remain unchanged in the layout.
- lytedev 5y agoDoesn't the textual representation not matter for using them in DB columns? The DB just uses the actual bytes, no?
- Macha 5y agoSQL is a textual format. Your DB driver may expect a UUID to be provided them in the standard string format. If your language lacks a standard UUID type, the drivers may expect you to provide UUIDs as strings even when using parameter binding. e.g. MySQL accepts only "no dashes" and the standard textual format: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_is-uuid https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functi... Postgres is a bit more flexible, but still expects hyphens to be after multiples of four characters if present: https://www.postgresql.org/docs/9.1/datatype-uuid.html https://www.postgresql.org/docs/9.1/datatype-uuid.html
- lytedev 5y agoThis is a good point. Thank you!
- gregoriol 5y agoThe important part is the number of bits used for storage; the textual version is only for humans
- weird-eye-issue 5y agoApplication level code validates UUIDs based on a specific format not to mention what the specific database might expect depending on the data type
- lytedev 5y agoThis sounds like a mistake? When/why should the application validate the format of a UUID?
- cratermoon 5y agoWhy shouldn't they?
- therealdrag0 5y agoWhen our services get Strings in requests that are UUIDs we convert them to typed java.util.Uuid objects, if they're not valid they get rejected.
- dnautics 5y agodepends on the DB. And it depends on your framework. Last I checked Django from about 5 years ago? still shipped uuids as text fields to the database.
- Macha 5y agoDB supports from "None" (SQLite) to "We'll give you some functions to work on text/ints that are supposed to be UUIDs" (MySQL) to "It's an actual native data type" (Postgres) among the 3 most common databases used by Django users, so it's hard to blame Django for going with a lowest common denominator approach.
- dnautics 5y agoI have since switched to Elixir/Ecto, and it just "does the right thing" in all of the above databases. Also, I think SQLite is capabale of supporting uuid with one of the plugins that you can add into the amalgamation with a compile switch, in either case ideally the framework would support it transparently.
- techdragon 5y agoI’m not sure this isn’t true, at least for PostgreSQL… I’m maintaining a ULID field library for Django and I’m reasonably sure that it’s getting sent to PostgreSQL as a UUID specific data type.
- athenot 5y agoFor human readability, I've always prefered encoding UUIDs in base 64 and swapping a couple characters. If I'm going to have some ugly identifier in a URL, I might as well make it more concise. I think youtube does something similar with their video IDs.