Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

31–40 of 236 posts

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

#31

Post by Daegalus »

pphysch wrote: post #17

I implemented something similar recently, but opted to write my own UUIDv7 that uses the last 16 flexible bits for a "type ID". That allows 65K different data models, which should be more than enough. Could even partition that further to store a node ID for a globally distributed setup. So it's got all of the above perks, but it also an actual UUID and fits in a Postgres UUID column. It's very cool to be able to reso…

Ideally, you should version that as UUIDv8. Since that is a more custom implementation, but I guess changing the random bits with type info works fine for UUIDv7, they jsut arent random anymore.

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

#32

Post by goostavos »

jszymborski wrote: post #23

This is very similar to how I generate IDs in a project I'm working on. Example: |-A-|-|------------B--------------| NMSPC-9TWN1-HR7SV-MTX00-0H8VP-YCCJZ A = Namespace, padded to 5 chars. Max 5 chars. Uppercase. B = Blake3 hashed microtime with a random key. I like how it folds in a time component but that it also doesn't reveal the time it was generated. Here's the snippet: https://gist.github.com/jszym/d3c7907b7b6e9…

Namespacing identifiers in general is a great idea for handling those class of integration tests which cannot be fully isolated. It makes it easy to write all kinds of garbage from even concurrently running tests all without any of them colliding or accidentally reading each others writes (because they are themselves namespace aware!). It's low effort to get all the pieces of your system to play along (often entirely transparent via DI), but gives a huge power to weight ratio. Basically deletes an entire class of problems which usually plague large, mature test suits

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

#33

Post by ceejayoz »

stronglikedan wrote: post #14
bombela wrote: post #13

I have some complaints about UUIDs. Why not just combining time + random number without the ceremony of UUID versioning. And for when locality doesn't matter, just use a 128bit random number directly. And in my experience most people somehow think a UUID must be stored into the human friendly hex representation, dashes included. Wasting so much space in database, network, memory.

> combining time + random number You can't guarantee that this will be globally unique.

No identifier can guarantee that. We just get close enough to be acceptable.

Per Wikipedia, the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion.

so-youre-saying-theres-a-chance.gif

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

#34

Post by pphysch »

Daegalus wrote: post #31
pphysch wrote: post #17

I implemented something similar recently, but opted to write my own UUIDv7 that uses the last 16 flexible bits for a "type ID". That allows 65K different data models, which should be more than enough. Could even partition that further to store a node ID for a globally distributed setup. So it's got all of the above perks, but it also an actual UUID and fits in a Postgres UUID column. It's very cool to be able to reso…

Ideally, you should version that as UUIDv8. Since that is a more custom implementation, but I guess changing the random bits with type info works fine for UUIDv7, they jsut arent random anymore.

Not every bit of UUID is required to be random.

The goals are smallness, uniqueness, monotonicity, resistance to enumeration attacks, etc. Not randomness for randomness sake.

My UUIDv7+ can be consumed as a standard UUIDv7. It is not intended to be v8. A program can treat the last 16 bits as random noise if it wants.

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

#36

Post by koito17 »

How does this compare to a SQUUID for sorting or nano-id for human readability? Both are options I've used in the past when using databases like Datomic or XTDB. SQUUIDs in particular because I have a UUID that can be ordered by timestamp, nano-id when prototyping things and I want meaningful prefixes in my entity IDs rather than a bunch of UUIDs.

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

#37

Post by ajanuary »

Neat, I like the type safe prefix idea.

Personally, I rarely find I need ids to be sortable, so I just go with pure randomness.

I also like to split out a part of the random section into a tag that is easier for me to visually scan and match up ids in logs etc.

I call my ID format afids [0]

[0] https://github.com/aJanuary/afid

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

#38

Post by duped »

ceejayoz wrote: post #33
stronglikedan wrote: post #14

Earlier quoted context omitted.

> combining time + random number You can't guarantee that this will be globally unique.

No identifier can guarantee that. We just get close enough to be acceptable. Per Wikipedia, the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion. so-youre-saying-theres-a-chance.gif

A billion is not that big of a number for UUIDs

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

#39

Post by pizzapill »

theptip wrote: post #20
ajkjk wrote: post #4

Unrelated, but this links to "Crockford's alphabet", https://www.crockford.com/base32.html , which is a base-32 system that includes all alphanumeric characters except I and L (which are confusable with 1), O (which is confusable with 0), and U (????). The page says the reason for excluding U is "accidental obscenity'. What the heck is it talking about?

The Scunthorpe problem? https://en.m.wikipedia.org/wiki/Scunthorpe_problem

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

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

#40

Post by Daegalus »

pphysch wrote: post #34
Daegalus wrote: post #31

Earlier quoted context omitted.

Ideally, you should version that as UUIDv8. Since that is a more custom implementation, but I guess changing the random bits with type info works fine for UUIDv7, they jsut arent random anymore.

Not every bit of UUID is required to be random. The goals are smallness, uniqueness, monotonicity, resistance to enumeration attacks, etc. Not randomness for randomness sake. My UUIDv7+ can be consumed as a standard UUIDv7. It is not intended to be v8. A program can treat the last 16 bits as random noise if it wants.

I am aware, just saying per spec, its supposed to be random bit data, thats all I was saying. I am familiar with a spec since I maintain a UUID library that has 6,7, and a custom 8 implemented.

It can have extra monotonicity data instead, per section 6.2 but ideally its random. Again, Not saying you can't do what you are doing, I just know per the conversations while the draft was gathering feedback, your type of change was intended to be done as uuidv8

Post reply on HN