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

11–20 of 172 posts

Re: New UUID Formats

#11

Post by theptip »

stevesimmons wrote: post #3

This had appeared a few times before at earlier stages of the draft process... https://news.ycombinator.com/item?id=28088213 [244 comments] Personally, I really like UUIDv7, except I transform the UUID to a 25-character string which has all the same properties except it doesn't look like a UUID. The last thing I want is my index of time-sortable UUIDs getting contaminated with with some UUIDv4 fully random ones. Sinc…

Can’t you just check the “version” bits and reject if it’s not 4/7? Or are you worried about someone generating a completely random (non-compliant) set of bits that happens to parse as a v4/7

Re: New UUID Formats

#12

Post by chrismorgan »

kstenerud wrote: post #4

It's a shame they didn't finally drop big endian. Little endian won out and our newer protocols should reflect that for efficiency's sake.

Big-endianness is mandatory for opaque bytewise sorting (or lexicographic ordering in string form), which is a very desirable property of UUIDv6 and UUIDv7.

Re: New UUID Formats

#13

Post by rekwah »

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].

Functionally, UUIDv7 might be the _same_ but the hope would be for a more rigid specification for interoperability.

[1]: https://github.com/ahawker/ulid

[2]: https://github.com/ulid/spec

[3]: https://github.com/ulid/spec/issues/11

Re: New UUID Formats

#16

Post by ripe »

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.

Re: New UUID Formats

#17

Post by wyager »

kstenerud wrote: post #4

It's a shame they didn't finally drop big endian. Little endian won out and our newer protocols should reflect that for efficiency's sake.

I guarantee you that byte order swapping is not the limiting factor on the efficiency of any system involving UUIDs on the wire.

Re: New UUID Formats

#18

Post by [deleted] »

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.

[deleted]

Re: New UUID Formats

#19

Post by amluto »

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 struct {
        unsigned32  time_low;
        unsigned16  time_mid;
        unsigned16  time_hi_and_version;
        unsigned8   clock_seq_hi_and_reserved;
        unsigned8   clock_seq_low;
        byte        node[6];
    } uuid_t;
Those aren’t bytes — they’re integers of various sizes. (Hint: do not use integer types in C code for portable data structures. ntohl, etc are a mess. Just use arrays of bytes.)

I don’t know the whole history, but MS somehow took this structure at face value and caused problems like this:

https://github.com/uuid-rs/uuid/issues/277

So, if you want to do anything (e.g. sorting) that depends on the representation of a UUID (or even depends on converting between string and binary representations), be aware that UUIDs coming from Windows may be little-endian. In my book, this is a Windows bug, but opinions may differ here.

Re: New UUID Formats

#20

Post by amluto »

kstenerud wrote: post #4

It's a shame they didn't finally drop big endian. Little endian won out and our newer protocols should reflect that for efficiency's sake.

No, they should have tried to find a way to drop little endian. A cycle or two when generating UUIDs is irrelevant, and almost all UUID implementations, and most of the RFC 4122 text, are big-endian.
Post reply on HN