4 ms·

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 withi

by 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?
- 015a 3y ago
  But my point is: When is that standardization actually leveraged? Literally, tactically, what does "you know what to expect as a developer" mean? When is this standardization used in a fashion that enables more capability than just "the ID is a string don't worry about it"? The realistic answer is: it isn't, because pre-UUIDv7 there was literally nothing about the UUID spec that conferred more capability than just a random string. And, truly; people used them as "just gimme a random string" all the flipping time. The pipes of the internet are filled with JSON that contains UUIDs-in-a-string-field, 4 bytes wasted to hyphens, 1 byte wasted to a version number, none of that is in service to anyone or anything.
  - 3y ago
vivzkestrel 3y ago
what do you even mean by "Why are we validating ids"? zzzzyyyy-zyzy-zyzy-zzyyzzyyzzyy does this look like a valid ID? I could totally store this in the database if there was no validation involved
- sagarm 3y ago
  From GP (and my) perspective, the useful part of UUID is that it's 16 bytes. This is usually for formatted as 32 hex digits with dashes in specific places. The version/variant bits are the pointless part. Of course if you put the 16 bytes on the wire you would still have some encoding (perhaps 22 base64 characters?) that requires decoding/validation, but in memory and in your DB it's just 16 bytes of opaque data.

by 015a 3y ago

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?
015a 3y ago
But my point is: When is that standardization actually leveraged? Literally, tactically, what does "you know what to expect as a developer" mean? When is this standardization used in a fashion that enables more capability than just "the ID is a string don't worry about it"? The realistic answer is: it isn't, because pre-UUIDv7 there was literally nothing about the UUID spec that conferred more capability than just a random string. And, truly; people used them as "just gimme a random string" all the flipping time. The pipes of the internet are filled with JSON that contains UUIDs-in-a-string-field, 4 bytes wasted to hyphens, 1 byte wasted to a version number, none of that is in service to anyone or anything.
- 3y ago

vivzkestrel 3y ago

what do you even mean by "Why are we validating ids"? zzzzyyyy-zyzy-zyzy-zzyyzzyyzzyy does this look like a valid ID? I could totally store this in the database if there was no validation involved

sagarm 3y ago
From GP (and my) perspective, the useful part of UUID is that it's 16 bytes. This is usually for formatted as 32 hex digits with dashes in specific places. The version/variant bits are the pointless part. Of course if you put the 16 bytes on the wire you would still have some encoding (perhaps 22 base64 characters?) that requires decoding/validation, but in memory and in your DB it's just 16 bytes of opaque data.