News for hackers. Stuff that matters.
Re:Now that UUIDv7 is lexicographic, does that mean there is... by a-s-k-af on Monday June 17, 2024 @08:41PM (#40712873)
- 128-bit compatibility with UUID - 1.21e+24 unique ULIDs per millisecond - Lexicographically sortable! - Canonically encoded as a 26 character string, as opposed to the 36 character UUID - Uses Crockford's base32 for better efficiency and readability (5 bits per character) - Case insensitive - No special characters (URL safe) - Monotonic sort order (correctly detects and handles the same millisecond)

ULID's claim according to their official documentation are the above of which everything is taken care of by UUIDv7 officially now. Why should I or not shift back to UUIDv7?

Re:Now that UUIDv7 is lexicographic, does that mean there is... by stop50 on Tuesday June 18, 2024 @01:38AM (#40714373)
Some databases directly support uuid, so they can save it as the binary data itself.
Re:Now that UUIDv7 is lexicographic, does that mean there is... by dagss on Tuesday June 18, 2024 @02:27AM (#40714638)
Do NOT do that with MS-SQL. The uniqueidentifier type shuffles byes around and does not give you the ordering you want.

So whether you use ULID or UUIDv7, save it as binary(16) in MSSQL.

(There is a special custom UUID implementation someone made for MSSQL that will sort time-ordered on MSQL but nowhere else; IMO that is too niche...just use binary(16)...)

Re:Now that UUIDv7 is lexicographic, does that mean there is... by willvarfar on Tuesday June 18, 2024 @03:04AM (#40714878)
One big practical benefit of UUIDv7 is that it is hex, and simple substring extraction and from_hex functions, which are available pretty much everywhere, will be able to extract the timestamp portion from the high bits.

Having had to massage lots of data with base62 and other weirdnesses, this lowest common denominator approach is a really big selling point.

People often bikeshed about shaving a few bytes off the ID or something, but in most applications this is not very important and data storage formats are usually compressed so costs are about entropy not alphabet.

Re:Now that UUIDv7 is lexicographic, does that mean there is... by SahAssar on Tuesday June 18, 2024 @02:46AM (#40714757)
HN guidelines say "please use the original title, unless it is misleading or linkbait; don't editorialize".

This should probably be titled "uuidv7: A JavaScript implementation of UUID version 7"

Re:Now that UUIDv7 is lexicographic, does that mean there is... by willvarfar on Tuesday June 18, 2024 @03:01AM (#40714859)
RFC 9562 to add ULID-variants to the UUID spec is taking forever to standardize! Can't we just get it through already, and pester all mainstream frameworks and databases to support it please?

The RFC https://www.rfc-editor.org/rfc/rfc9562 lists 16 prior ULID schemes, and it is obviously not exhaustive because I've bumped into lots of hand-rolled schemes over the years.

In this case, standardization helps. Being able to have conversations about using UUIDv7 rather than having to bikeshed on the merits of which of the prior schemes fit and why would be sooooo much easier in corporate environments!