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

New UUID Formats

ietf.org

Post reply on HN
Print view View original

51–60 of 172 posts

Re: New UUID Formats

#51

Post by quotemstr »

amluto wrote: post #19

Fortunately this is a bit less relevant today as Windows loses market share in database and server applications, but: UUIDs have historically massively screwed up endian handling. While this new draft discusses sorting UUIDs as strings of octets (bytes) and the text of RFC4122 is fairly explicit about most significant bytes coming first, the C UUID structure in RFC 4122 appendix A is entirely misguided: typedef struc…

Little endian won. I don't see the point of maintaining theoretical compatibility with big endian systems that are at best esoteric right now and soon to be extinct. Likewise, every reasonable platform aligns data fields on natural alignment these days. It's just a waste of effort to make software portable to evolutionary dead ends.

Re: New UUID Formats

#52

Post by davidjfelix »

operator-name wrote: post #29

With the introduction of UUIDv8, my fun script to generate vanity uuids[0] can finally be spec comfortant! [0]: https://github.com/operator-name/vanity-uuid

I've been staring at the supposedly readable and memorable uuid for like 4 minutes without any idea what it says.

Re: New UUID Formats

#53

Post by hoten »

ripe wrote: post #16

Side note: I love the HTML format of these IETF RFCs, as in TFA. Over the decades, I was used to seeing the old text format (which I like), but this one is particularly easy on the eye, especially on my Android phone.

Only mobile issue I see is there is a really long link that overflows the intended document width, which introduces an horizontal scrollbar. That makes scrolling a bit finicky on mobile.

Re: New UUID Formats

#54

Post by operator-name »

davidjfelix wrote: post #52
operator-name wrote: post #29

With the introduction of UUIDv8, my fun script to generate vanity uuids[0] can finally be spec comfortant! [0]: https://github.com/operator-name/vanity-uuid

I've been staring at the supposedly readable and memorable uuid for like 4 minutes without any idea what it says.

Yeah, looking back I could have done a bit more than simple substitution. Since the sentences don't gave meaning, interpreting between 1 as i vs l is especially difficult.

5eedbed5-f05e-b055-ada0-d15ab11171e5

seedbeds-fose-boss-adao-disabilities

"Memorable" was definitely tongue in cheek, as was the spec bending.

Re: New UUID Formats

#55

Post by jasonwatkinspdx »

zbuf wrote: post #39
GiorgioG wrote: post #22

I used to be a big proponent of using UUIDs for database PKs but I've found them inherently difficult to work with. It's much easier to remember/recognize an integer based PK when troubleshooting a data problem. This isn't to say you shouldn't use UUIDs at all, but I much prefer to use an "ExternalId" column of UUID type if you don't want to expose your integer based PKs externally.

"Unique IDs" _can_ be super really easy to work with if they're not so baffling complicated. A random string generated using quality randomness can be adjusted to length to suit the quantity of data (negligible probability of a collision) which in most cases is very short. It's easy to increase the length as you get more data. They are visually very different for each item of data. They're evenly spread which means t…

Using purely random ids in your database destroys locality. They mention this in the introduction:

> Non-time-ordered UUID versions such as UUIDv4 have poor database index locality. Meaning new values created in succession are not close to each other in the index and thus require inserts to be performed at random locations. The negative performance effects of which on common structures used for this (B-tree and its variants) can be dramatic.

The V7 ids work similarly to what you like, as they're just a unix timestamp and 74 bits of pseudorandom data (they present several different schemes you could use to generate this randomness, but the basic birthday bound says we'd need to be above 100 billion id's generated in a single millisecond to worry about collisons. Obviously most systems are nowhere near that territory.

So using these id's gives you the practical advantages of random uinique ids, but with the performance of autoincrement ids.

Re: New UUID Formats

#56

Post by wolverine876 »

quotemstr wrote: post #51
amluto wrote: post #19

Fortunately this is a bit less relevant today as Windows loses market share in database and server applications, but: UUIDs have historically massively screwed up endian handling. While this new draft discusses sorting UUIDs as strings of octets (bytes) and the text of RFC4122 is fairly explicit about most significant bytes coming first, the C UUID structure in RFC 4122 appendix A is entirely misguided: typedef struc…

Little endian won. I don't see the point of maintaining theoretical compatibility with big endian systems that are at best esoteric right now and soon to be extinct. Likewise, every reasonable platform aligns data fields on natural alignment these days. It's just a waste of effort to make software portable to evolutionary dead ends.

You're saying it won for this application (UUIDs)? Universally?

What is the most common remaining use of big endian?

Re: New UUID Formats

#57

Post by mort96 »

quotemstr wrote: post #51
amluto wrote: post #19

Fortunately this is a bit less relevant today as Windows loses market share in database and server applications, but: UUIDs have historically massively screwed up endian handling. While this new draft discusses sorting UUIDs as strings of octets (bytes) and the text of RFC4122 is fairly explicit about most significant bytes coming first, the C UUID structure in RFC 4122 appendix A is entirely misguided: typedef struc…

Little endian won. I don't see the point of maintaining theoretical compatibility with big endian systems that are at best esoteric right now and soon to be extinct. Likewise, every reasonable platform aligns data fields on natural alignment these days. It's just a waste of effort to make software portable to evolutionary dead ends.

This isn't about compatibility with big-endian machines. This is about compatibility between different uuid libraries, potentially on different operating systems, all on little endian CPU architectures.

Re: New UUID Formats

#58

Post by kortex »

rekwah wrote: post #13
kbumsik wrote: post #8

UUIDv7 looks interesting, but how is it different from ULID [1] in practice? I was considering using ULID for a upcoming new project because it is lexicographically sortable but it looks like UUIDv7 just can replace that. [1]: https://cran.r-project.org/web/packages/ulid/vignettes/intro...

As the author of a popular ULID implementation in python[1], the spec has no stewardship anymore. The specification repo[2] has plenty of open issues and no real guidance or communication beyond language implementation authors discussing corner cases and the gaps in the spec. The monotonic functionality is ambiguous (at best), doesn't consider distributed id generation, and is implemented differently per-language [3]…

I've bee using ULIDs in python for about a year now and so far have been super happy with them, so a) thank you for maintaining this! b) I always felt a bit uneasy about the way the spec describes the monotonicity component. Personally I just rely on the random aspect as I am fortunate enough to say that two events in the same millisecond are effectively simultaneous.

At that point, it's basically just UUID7 with Crockford base32 encoding, more or less.

IMHO the in-process monotonically increasing feature of ULID is misguided. As you mention, distributed ids are a pain. The instant you start talking distributed, monotonic counters or orderable events (two threads count as distributed in this case), you need to talk things like Lamport clocks or other hybrid clock strategies. It's better to reach for the right tools in this case, vs half-baked monotonic-only-in-this-process vague guarantee.

Re: New UUID Formats

#59

Post by tech2 »

wolverine876 wrote: post #56
quotemstr wrote: post #51

Earlier quoted context omitted.

Little endian won. I don't see the point of maintaining theoretical compatibility with big endian systems that are at best esoteric right now and soon to be extinct. Likewise, every reasonable platform aligns data fields on natural alignment these days. It's just a waste of effort to make software portable to evolutionary dead ends.

You're saying it won for this application (UUIDs)? Universally? What is the most common remaining use of big endian?

TCP/IP might be a reasonable example. There's a reason "network byte order" and "big endian" are the same thing.

Re: New UUID Formats

#60

Post by oittaa »

canadiantim wrote: post #50

How would one go about trying to use UUID 7 in a Postgres database / python codebase now?

I made a simple Python test library that extends the standard UUID class with UUIDv6 and UUIDv7. You might want to check it out. https://github.com/oittaa/uuid6-python

The official UUID Draft repository has also some alternatives if you'd like to check those out. https://github.com/uuid6/prototypes

Postgres supports UUIDs with any version number natively so you can then do something like this with it:

  create table data (id uuid, firstname varchar(100));
  insert into data (id, firstname) values ('017f21cf-d130-7cc3-98c4-dc0c0c07398f', 'John');
  select * from data;
Post reply on HN