4 ms·

Doesn't the textual representation not matter for using them in DB columns? The DB just uses the actual bytes, no?

Macha 5y ago
SQL 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 ago
  This is a good point. Thank you!
gregoriol 5y ago
The important part is the number of bits used for storage; the textual version is only for humans
weird-eye-issue 5y ago
Application 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 ago
  This sounds like a mistake? When/why should the application validate the format of a UUID?
  - cratermoon 5y ago
    Why shouldn't they?
  - therealdrag0 5y ago
    When 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 ago
depends 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 ago
  DB 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 ago
    I 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 ago
  I’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.

SQL 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 ago
This is a good point. Thank you!

gregoriol 5y ago

The important part is the number of bits used for storage; the textual version is only for humans

weird-eye-issue 5y ago

Application 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 ago
This sounds like a mistake? When/why should the application validate the format of a UUID?
- cratermoon 5y ago
  Why shouldn't they?
- therealdrag0 5y ago
  When 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 ago

depends 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 ago
DB 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 ago
  I 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 ago
I’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.