3 ms·

> No one else really needs to care how you produced your 16 bytes UUID isn't about how it's done, it's about what it is. Instead of everyone doing something d

> No one else really needs to care how you produced your 16 bytes UUID isn't about how it's done, it's about what it is. Instead of everyone doing something differently, everyone can just comply with UUID. Instead of having to repeat it across your docs that the IDs of this entity are sortable, you can just say they are UUIDv7. If someone wants to extract the timestamp from your ID, they don't need to figure out which (32, 48, 50?) bits are the timestamp nor what resolution the timestamp has because you can tell them UUIDv7. You don't have to write your own validation functions because you can tell the database that this hex string is a UUID and it can do it for you. You're probably making the case for Sqlite here which is very minimal, but something more full-featured like Postgres, I prefer these conveniences. I can tell because whenever I use Sqlite in a case where I could've used Postgres, I regret it!

015a 3y ago
But I feel the point is: None of that is a relevant concern IDs should take on. Most functional things related to e.g. embedding the record creation time within the ID is one of those "that's cool, but I've never seen anyone do it" kind of things. If you need to sort records by when they were created, there are probably three or four happened_at fields on the record you'd use (created_at in this case). If you need the exact time; those are there for that. Counter-argument: Well, you can save a few bytes on every record by getting rid of the created_at field and just using a UUIDv7. Maybe, but I've never seen anyone do it. What if you need to change the time the record was created? Are you planning to explain to all your integration providers the process of extracting a timestamp from a UUIDv7? What if you need to run complex SQL timestamp functions on created_at? Etc. Its cool, but it never actually happens. Once we enter the domain of "using the node id or timestamp or something to reduce the probability of ID collision", that's a totally reasonable responsibility within an ID's set of concerns. But, that's a very different need. > You don't have to write your own validation functions Why are we validating IDs? > but something more full-featured like Postgres, I prefer these conveniences. Agreed. I am a vocal UUID hyper-hater. UUIDs should be destroyed, and humanity would be (oh so slightly) better off if they had never existed. But, they're still a thing, and I think its cool that databases have hyper-specific types like this. My wish is Postgres would have other more sane automatic ID types and gen capability, in addition to uuid & autoincrement.
- arghwhat 3y ago
  The point of the timestamp in UUIDv7 is not to encode creation time, it is to provide some (coarse-grained) chronological sortability. Random primary keys are bad, but exposing incremental indexes to the public is also bad, and hacking on a separate unique UUID for public use is also bad. UUIDs are over-engineered for historical reasons, and UUIDv7 as raw 128 bits without the version encoding would be nicer. But, to the end-user it's just a few lost bits in a 128-bit ID with an odd standard for hyphenation. The standardization means you know what to expect as developer, instead of every DB rolling their own unique 128-bit ID system with its own guarantees and weirdnesses.
  - masspro 3y ago
    > hacking on a separate unique UUID for public use is also bad. Is it bad just because of the extra bytes used, or something else?
    - deleted 3y ago
      [deleted]
    - arghwhat 3y ago
      You need to maintain a UNIQUE index and have two IDs, with the one set as primary key solely existing for on-disk ordering. It's a nasty hack.
      - wiredfool 3y ago
        Postgres doesn't use the primary key for on disk ordering. MySQL does.
        arghwhat 3y ago
        Ah, good point. The concern about on-disk ordering then only applies to other databases. I suppose the index order may still be relevant for PostgreSQL?
  - 3y ago
hulitu 3y ago
> Instead of everyone doing something differently, everyone can just comply with UUID. With which UUID ? UUID v1 ? UUID v2 ? UUID v3 ? ... UUID v7 ?
- akira2501 3y ago
  UUID has the version number and variant number encoded in the generated UUID. You can just examine the UUID to determine which version it is.
  - acchow 3y ago
    Unless the random bits don’t follow those conventions.
    - Lammy 3y ago
      It isn't a UUID if it doesn't contain those flag bits in their expected positions. A "random" UUID has only 122 bits of randomness for this reason.
  - Lammy 3y ago
    The UUID specs are still confusing (or at least were to me lol) because the words "version" and "variant" both just say that something changes, not what is changing or why it's changing. version from Latin vertere "to turn, turn back, be turned; convert, transform, translate; be changed" variant from Latin variare "change, alter, make different," In my own UUID/GUID code I have taken to calling them "behavior" and "layout", respectively: https://github.com/okeeblow/DistorteD/blob/NEW%E2%80%85SENSATION/Globe%20Glitter/lib/globeglitter.rb#L66-L79 https://github.com/okeeblow/DistorteD/blob/NEW%E2%80%85SENSA...
    - akira2501 3y ago
      4.1.1 The variant field determines the layout of the UUID. That is, the interpretation of all other bits in the UUID depends on the setting of the bits in the variant field. As such, it could more accurately be called a type field; we retain the original term for compatibility. 4.1.3 The version number is in the most significant 4 bits of the time stamp (bits 4 through 7 of the time_hi_and_version field). The following table lists the currently-defined versions for this UUID variant. The version is more accurately a sub-type; again, we retain the term for compatibility. It's recognized in the RFC and all you've done is broke compatibility for fashion.

015a 3y ago

But I feel the point is: None of that is a relevant concern IDs should take on. Most functional things related to e.g. embedding the record creation time within the ID is one of those "that's cool, but I've never seen anyone do it" kind of things. If you need to sort records by when they were created, there are probably three or four happened_at fields on the record you'd use (created_at in this case). If you need the exact time; those are there for that. Counter-argument: Well, you can save a few bytes on every record by getting rid of the created_at field and just using a UUIDv7. Maybe, but I've never seen anyone do it. What if you need to change the time the record was created? Are you planning to explain to all your integration providers the process of extracting a timestamp from a UUIDv7? What if you need to run complex SQL timestamp functions on created_at? Etc. Its cool, but it never actually happens. Once we enter the domain of "using the node id or timestamp or something to reduce the probability of ID collision", that's a totally reasonable responsibility within an ID's set of concerns. But, that's a very different need. > You don't have to write your own validation functions Why are we validating IDs? > but something more full-featured like Postgres, I prefer these conveniences. Agreed. I am a vocal UUID hyper-hater. UUIDs should be destroyed, and humanity would be (oh so slightly) better off if they had never existed. But, they're still a thing, and I think its cool that databases have hyper-specific types like this. My wish is Postgres would have other more sane automatic ID types and gen capability, in addition to uuid & autoincrement.

arghwhat 3y ago
The point of the timestamp in UUIDv7 is not to encode creation time, it is to provide some (coarse-grained) chronological sortability. Random primary keys are bad, but exposing incremental indexes to the public is also bad, and hacking on a separate unique UUID for public use is also bad. UUIDs are over-engineered for historical reasons, and UUIDv7 as raw 128 bits without the version encoding would be nicer. But, to the end-user it's just a few lost bits in a 128-bit ID with an odd standard for hyphenation. The standardization means you know what to expect as developer, instead of every DB rolling their own unique 128-bit ID system with its own guarantees and weirdnesses.
- masspro 3y ago
  > hacking on a separate unique UUID for public use is also bad. Is it bad just because of the extra bytes used, or something else?
  - deleted 3y ago
    [deleted]
  - arghwhat 3y ago
    You need to maintain a UNIQUE index and have two IDs, with the one set as primary key solely existing for on-disk ordering. It's a nasty hack.
    - wiredfool 3y ago
      Postgres doesn't use the primary key for on disk ordering. MySQL does.
      - arghwhat 3y ago
        Ah, good point. The concern about on-disk ordering then only applies to other databases. I suppose the index order may still be relevant for PostgreSQL?
- 3y ago

hulitu 3y ago

> Instead of everyone doing something differently, everyone can just comply with UUID. With which UUID ? UUID v1 ? UUID v2 ? UUID v3 ? ... UUID v7 ?

akira2501 3y ago
UUID has the version number and variant number encoded in the generated UUID. You can just examine the UUID to determine which version it is.
- acchow 3y ago
  Unless the random bits don’t follow those conventions.
  - Lammy 3y ago
    It isn't a UUID if it doesn't contain those flag bits in their expected positions. A "random" UUID has only 122 bits of randomness for this reason.
- Lammy 3y ago
  The UUID specs are still confusing (or at least were to me lol) because the words "version" and "variant" both just say that something changes, not what is changing or why it's changing. version from Latin vertere "to turn, turn back, be turned; convert, transform, translate; be changed" variant from Latin variare "change, alter, make different," In my own UUID/GUID code I have taken to calling them "behavior" and "layout", respectively: https://github.com/okeeblow/DistorteD/blob/NEW%E2%80%85SENSATION/Globe%20Glitter/lib/globeglitter.rb#L66-L79 https://github.com/okeeblow/DistorteD/blob/NEW%E2%80%85SENSA...
  - akira2501 3y ago
    4.1.1 The variant field determines the layout of the UUID. That is, the interpretation of all other bits in the UUID depends on the setting of the bits in the variant field. As such, it could more accurately be called a type field; we retain the original term for compatibility. 4.1.3 The version number is in the most significant 4 bits of the time stamp (bits 4 through 7 of the time_hi_and_version field). The following table lists the currently-defined versions for this UUID variant. The version is more accurately a sub-type; again, we retain the term for compatibility. It's recognized in the RFC and all you've done is broke compatibility for fashion.