Live data from Hacker News

Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

github.com

201–210 of 236 posts

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#201

Assuming you don't need to use UUIDv7 (or any UUID's) then https://github.com/segmentio/ksuid provides a much bigger keyspace. You could just append a string prefix if you wanted to namespace, but the chance of collisions of a ksuid is many times smaller than a UUID of any version. ksuid is the best general purpose id generator with sort-able timestamps I've found and has libraries in most languages. UUID v1-7 are wa…

I have a thin JavaScript package published which generates type-prefixed KSUIDs. KSUID is a great format assuming you can spare the extra bits (which is most people)

[1] https://github.com/sophiabits/resource-id

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#202

Earlier quoted context omitted.

E-Mail accounts seem the worst. Just lets write letters again, if you need a pencil I recommend penisland.net

Penis mean “tail” in Latin.

As they say Your pen is Our business!

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#203

UUIDv7 has been taking HN by storm for years now! When is it going to become a proper standard, and when are libraries and databases and all the rest going to natively support it?

What kind of support do you expect? I'm pretty sure that absolute majority of software does not care about any particular bits in UUID, so you can use it today. If some software cared about any particular bits, just imitate UUIDv4, I mean those bits could be randomly generated as well. If you need generation procedure, write it yourself, it's easy.

+1

IDs generation is usually private to a company scope and rarely need to be "universally unique".

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#204
Something really nice about type prefixes in IDs is it makes “Global Object Identification” [1] in GraphQL super straightforward. The node query can simply inspect the ID and immediately know where to fetch the object from, whereas with “regular” IDs you either need to perform a bunch of database queries or otherwise maintain some index that maps IDs->types.

Not implementing this isn’t the end of the world, but it makes refetching individual bits of data in your cache far easier. It’s really nice being able to implement it basically for free.

[1] https://graphql.org/learn/global-object-identification/

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#205
post #46

Neat! Love the "type-safe" prefix; we'd called them "tagged ids" in our ORM that auto-prefixes the otherwise-ints-in-the-db with similar per-entity tags: https://joist-orm.io/docs/advanced/tagged-ids We'd used `:` as our delimiter, but kinda regretting not using `_` because of the "double-click to copy/paste" aspect... In theory it'd be really easy to get Joist to take "uuid columns in the db" and turn them into "typ…

My company has a typed internal ID system that originally used colons as delimiters but we quickly switched to dots (.) as the delimiter because it’s very annoying to have url-encoded IDs balloon in size because colons need to be %-encoded. Makes your urls ugly and long.

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#206

Earlier quoted context omitted.

Presumably base 32 means 26 letters + 10 digits - 4 banned letters So adding an excluded letter is not easy.

Why not use base-31 and (optionally) more characters? (Or go upper and lower or add a symbol if you had to stay with a fixed-size and base-32 for some reason)

Because Base32 is just bit shifting and then converting the 5 bits into a char, and vice versa. Doing Base31 requires base conversion.

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#207

Earlier quoted context omitted.

Thanks for the feedback! We have tests for the base32 encoding which is the most complicated part of the implementation ( https://github.com/jetpack-io/typeid-go/blob/main/base32/bas... ) but your point stands. We'll add a more rigorous test suite (particularly as the number of implementations across different languages grows, and we want to make sure all the implementations are compatible with each other) Re: prefix…

> Re: prefix, is the concern that I haven't defined the allowed character set as part of the spec? It would be great if you add suggestions for compound types (like “article-comment”) in README as OP stated as well.

It seems that's not allowed currently, if I'm reading it right. I'm not sure I like `-` very much. The reason why I don't like it is because of how double-click to select and line breaking works for the dash. Maybe allowing `_` in the typename, and the have the rightmost `_` serve as the separator might be more consistent.

But also, I'm bike-shedding and its only an ID

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#208

Earlier quoted context omitted.

You could argue that U can be confused with V.

A vaguely related historical tangent is that V and U used to be just two ways of writing the same letter in Early Modern English. Which I imagine is why W is named as "double U" in speaking.

That is indeed why w is named "double u" in English (and "double v" in French. And why it's a vowel in Welsh.

See more from jan Misali: https://www.youtube.com/watch?v=sg2j7mZ9-2Y

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#209
post #183

Earlier quoted context omitted.

analratassart would probably be just as bad

ianal

I realise you posted this as a joke, but the first time I saw this, I was so confused. I thought the comment was starting with "I anal" before I read the rest of the post only to compute it means "I Am Not A Lawyer"

Re: Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs

#210
Nice. I should use a similar id with ULID.

Although, if stored in a DB, I would probably split the tag and the id in 2 separate columns, because DBMS often have a dedicated efficient UUID field type.

A little client code wrapper can make that transparent.

Post reply on HN