3 ms·

>With the release of UUIDv7 that offers some benefits as ULIDs and are native to Postgres as of December 2024 (see the commit here), it might be better to switc

by aftbit 2y ago

>With the release of UUIDv7 that offers some benefits as ULIDs and are native to Postgres as of December 2024 (see the commit here), it might be better to switch to UUIDv7 in the future if one doesn’t care about URL friendliness. Yes, I think UUIDv7 would be a much better choice especially because you could continue to use the UUID type in postgres and not need to devolve to text. You could also choose to encode the IDs with base32/58/64 at the edge to make them shorter and more URL friendly, though that adds a complexity to your application in tracking database IDs separately from public IDs. I wish UUID would specify a more url-friendly standard representation format beyond the hex string with dashes.

layer8 2y ago
What’s wrong with the hex-and-dash representation? It’s the textual representation recommended by RFC 9562, and it’s immediately recognizable as a UUID. There’s also a URN namespace defined for it, if an absolute URI is needed or if one wants to be more explicit: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
- aftbit 2y ago
  It's too long. That's the only real problem with it. The same UUID in base58 would be: Xe22UfxT3rxcKJEAfL5373 Which is 22 characters instead of 36.
  - layer8 2y ago
    Too long with respect to what practical requirements? It’s still shorter than the usual hex representation of a full Git hash for example, and I don’t see calls to encode those as Base58. The dashes also make for a more readable structure.
    - sagarm 2y ago
      You get long ugly URLs. The system in work on often has 4-5 of these IDs in the URL, making working with them -- like copying and pasting them, or even extracting the particular id you care about from the path -- cumbersome.
      - TranquilMarmot 2y ago
        +1 for this, UUIDs in URLs is such a pain. For the app we're working on we went with UUIDs and often have 4+ in the URL as well. So ugly and cumbersome. Worst part is that you can't double-click on one to highlight the whole thing, you have to drag your cursor over it. At a previous company, we worked _really_ hard to come up with a "4x4" ID system (i.e. a1b2-c3d4) because they'd often have to be read over the phone. Originally, we worried we'd run out of them but after 15+ years it seems like they're still going strong.
aftbit 2y ago
Here's some python code that implements what I discussed: def decode_id(id): if id is None: return None return str(uuid.UUID(bytes=base58.b58decode(id))) def encode_id(id): if id is None: return None if not isinstance(id, uuid.UUID): id = uuid.UUID(hex=id) return base58.b58encode(id.bytes) def ensure_id(id): if id is None: return None try: return decode_id(id) except Exception: try: encode_id(id) except Exception: return None else: return id
TranquilMarmot 2y ago
We had a Django project using ULIDs and it just caused headache after headache when interacting with Postgres, and we had all sorts of weird extensions to try to get it working that blocked a Django upgrade. I ended up ripping it all out and just using UUIDv7 everywhere, much more standard.
timewizard 2y ago
> encode the IDs with base32/58/64 at the edge to make them shorter Having tried this I immediately regretted it. Storage is not costly enough to justify the additional pain points that you've correctly identified. > UUID would specify a more url-friendly standard representation There's always the 2.25 OID space via URN (urn:oid:2.25.12345...). In which case you encode the underlying integer directly without any grouping punctuation involved. For the same reason above you should use probably use a single encoding for all use cases, at which point, just using the ugly 8-4-4-4-12 will save you the most trouble.
- TranquilMarmot 2y ago
  I don't think they're suggesting storing them in base32/58/64, but just having that be how they're presented to the user. We do this in some of our APIs- if the URL has an ID of a specific length we try to turn it into a full UUID first before passing it on to other code. In the postgres database, the ID column is still a UUID type.
- aftbit 2y ago
  Not sure why your comment was flagged. I also somewhat regret using base58 UUIDs, but with sufficient DB and app-side helpers, and sufficient discipline to always convert at the edges, it became tolerable. It was the only option I could come up with to retrofit short IDs onto a system designed with UUIDs where a project owner decided our URLs needed to be shorter and prettier late in the development process.
tttp 2y ago
we encoded the id with a base that removes most vowels (to avoid generating words, potentially offensive ones, and added a checksum to prevent copy paste mistakes it worked quite well so far https://dxid.tttp.eu/ https://dxid.tttp.eu/
jerrygoyal 2y ago
why uuidv7 isn't url-friendly?
- aftbit 2y ago
  It is just too long. It does not include any illegal characters, but it is ~50% larger than it needs to be.

by aftbit 2y ago

layer8 2y ago

What’s wrong with the hex-and-dash representation? It’s the textual representation recommended by RFC 9562, and it’s immediately recognizable as a UUID. There’s also a URN namespace defined for it, if an absolute URI is needed or if one wants to be more explicit: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

aftbit 2y ago
It's too long. That's the only real problem with it. The same UUID in base58 would be: Xe22UfxT3rxcKJEAfL5373 Which is 22 characters instead of 36.
- layer8 2y ago
  Too long with respect to what practical requirements? It’s still shorter than the usual hex representation of a full Git hash for example, and I don’t see calls to encode those as Base58. The dashes also make for a more readable structure.
  - sagarm 2y ago
    You get long ugly URLs. The system in work on often has 4-5 of these IDs in the URL, making working with them -- like copying and pasting them, or even extracting the particular id you care about from the path -- cumbersome.
    - TranquilMarmot 2y ago
      +1 for this, UUIDs in URLs is such a pain. For the app we're working on we went with UUIDs and often have 4+ in the URL as well. So ugly and cumbersome. Worst part is that you can't double-click on one to highlight the whole thing, you have to drag your cursor over it. At a previous company, we worked _really_ hard to come up with a "4x4" ID system (i.e. a1b2-c3d4) because they'd often have to be read over the phone. Originally, we worried we'd run out of them but after 15+ years it seems like they're still going strong.

aftbit 2y ago

Here's some python code that implements what I discussed: def decode_id(id): if id is None: return None return str(uuid.UUID(bytes=base58.b58decode(id))) def encode_id(id): if id is None: return None if not isinstance(id, uuid.UUID): id = uuid.UUID(hex=id) return base58.b58encode(id.bytes) def ensure_id(id): if id is None: return None try: return decode_id(id) except Exception: try: encode_id(id) except Exception: return None else: return id

TranquilMarmot 2y ago

We had a Django project using ULIDs and it just caused headache after headache when interacting with Postgres, and we had all sorts of weird extensions to try to get it working that blocked a Django upgrade. I ended up ripping it all out and just using UUIDv7 everywhere, much more standard.

timewizard 2y ago

> encode the IDs with base32/58/64 at the edge to make them shorter Having tried this I immediately regretted it. Storage is not costly enough to justify the additional pain points that you've correctly identified. > UUID would specify a more url-friendly standard representation There's always the 2.25 OID space via URN (urn:oid:2.25.12345...). In which case you encode the underlying integer directly without any grouping punctuation involved. For the same reason above you should use probably use a single encoding for all use cases, at which point, just using the ugly 8-4-4-4-12 will save you the most trouble.

TranquilMarmot 2y ago
I don't think they're suggesting storing them in base32/58/64, but just having that be how they're presented to the user. We do this in some of our APIs- if the URL has an ID of a specific length we try to turn it into a full UUID first before passing it on to other code. In the postgres database, the ID column is still a UUID type.
aftbit 2y ago
Not sure why your comment was flagged. I also somewhat regret using base58 UUIDs, but with sufficient DB and app-side helpers, and sufficient discipline to always convert at the edges, it became tolerable. It was the only option I could come up with to retrofit short IDs onto a system designed with UUIDs where a project owner decided our URLs needed to be shorter and prettier late in the development process.

tttp 2y ago

we encoded the id with a base that removes most vowels (to avoid generating words, potentially offensive ones, and added a checksum to prevent copy paste mistakes it worked quite well so far https://dxid.tttp.eu/ https://dxid.tttp.eu/

jerrygoyal 2y ago

why uuidv7 isn't url-friendly?

aftbit 2y ago
It is just too long. It does not include any illegal characters, but it is ~50% larger than it needs to be.