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

51–60 of 236 posts

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

#51

Post by wongarsu »

stephen wrote: 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…

Reddit does something similar, but optimized for string length: elements have ids like "t3_15bfi0" where t3_ is a prefix for the type (t3 is a post, t1 a comment, t5 a subreddit, etc) and the remaining is a base36 encoding of the autoincrementing primary key.

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

#52

Post by jeremyjh »

AtNightWeCode wrote: post #25

An important aspect of identifiers is to not leak any information in the identifier. In some scenarios a prefix might be fine but less important things have been blocked by our dpo department.

Yeah, this idea makes me uneasy as well for the same reason. The natural conclusion would be to have DB frameworks automatically do this based upon code type names and that definitely feels like a leak, handing the world at large a roadmap to your internal system architecture.

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

#53

Post by tomnipotent »

changoplatanero wrote: post #43

what does k-sortable mean?

That if a hundred servers are generating (uuid, timestamp) tuples that are subsequently merged on a single machine, and sorted by uuid, it would have almost the same order as if sorted by timestamp.

This property is useful for RDBMS writes, when the UUID is used as a primary key and this locality ensures that fewer slotted pages need to be modified to write the same amount of data.

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

#54

Post by jeremyjh »

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.

Well UUIDv7 can be consumed as a UUIDv4 in the same way, its just 16 bytes. The point of the standard is to define how the particular bytes are chosen.

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

#56

Post by MR4D »

stronglikedan wrote: post #16
Racing0461 wrote: post #8

Earlier quoted context omitted.

yep, youtube video ids has/had? same issue where it would have things like fag/f4g etc in it. eg: google "allinurl:fag site:youtube.com"

You can prevent any obscenity, O and 0 confusion, and I and L confusion, just by excluding vowels. If someone interprets "f4g" in an offensive way, then they have bigger issues than can be dealt with in software.

Obscenities change with language. That’s why every language has them.

Even programming language have them. For instance, Basic has GOTO.

/j

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

#58

Post by nzgrover »

tomnipotent wrote: post #53
changoplatanero wrote: post #43

what does k-sortable mean?

That if a hundred servers are generating (uuid, timestamp) tuples that are subsequently merged on a single machine, and sorted by uuid, it would have almost the same order as if sorted by timestamp. This property is useful for RDBMS writes, when the UUID is used as a primary key and this locality ensures that fewer slotted pages need to be modified to write the same amount of data.

Is that what they mean by "used as the primary key in a database while ensuring good locality"/"database locality"? That read/write access will hit fewer disk pages?

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

#60

Post by kortex »

arcticbull wrote: post #26
stronglikedan wrote: post #16

Earlier quoted context omitted.

You can prevent any obscenity, O and 0 confusion, and I and L confusion, just by excluding vowels. If someone interprets "f4g" in an offensive way, then they have bigger issues than can be dealt with in software.

There was that time Delta generated an "H8GAYS" PNR. [1] Pretty sure that's valid Crockford encoding too :) however, to your point, it does rely on 'A'. "H8G4YS" would likely still offend someone out there, though, given the kerfuffle in [1]. [1] https://newsfeed.time.com/2013/12/17/delta-airlines-is-very-...

> But as White points out, it’s a bit surprising that Delta didn’t block this particular combination as a possibility. “I’m sure they removed many four-letter words that would be seen as offensive,” he tells the Post. “I’m surprised that ‘gays’ and ‘H8’ weren’t blocked as well.”

Oh sweet summer child (meaning Jeff White, not OP/GP). As someone who has implemented a censorship/filtering list, this is a UX problem on the same level of decideability as the halting problem. You can spend boundless time curating a list to flag/grawlix every possible string that would offend even the most prudish of prudes, and some would still get through. Such as the superficially benign "EATTHE"

https://www.dailymail.co.uk/news/article-2039662/Virginia-dr...

Post reply on HN