4 ms·
ULID seems like a better solution to me: still 128 bits but with a more compact canonical format and sensible timestamp and increment semantics. I guess it's no
by Robin_Message 3y ago
ULID seems like a better solution to me: still 128 bits but with a more compact canonical format and sensible timestamp and increment semantics.
I guess it's not far off a v7 UUID though.
https://github.com/ulid/spec https://github.com/ulid/spec
- JdeBP 3y agoAlternatively: UUID v7 and v8 seem like the better solution. They're the subject of a more formal standardization process; they're compatible with existing UUIDs because they correctly set the version number and variant fields; v7 has exactly the same 48-bit POSIX timestamp as an ULID; and they already have widespread transformations to and from machine-readable form. Picking something primarily because of its human-readable form rather than its machine-readable form is probably not the best decision criterion.
- newaccount74 3y agoUUIDv7 is nice because it's just a variant of UUID, which are already supported in very many databases and programming languages. And even if you are writing code for an obscure microprocessor where no implementation is available, the encoding scheme is well known and straightforward. ULID on the other hand depends on an uncommon encoding scheme. It is more complicated than hex encoding, so it's easy to make mistakes when implementing it. Finally, the encoding scheme is weird, because it "wastes" a few bits at the end, so if you are not careful enough you could end up in a situation where two ULIDs in text form are different but once you convert them to bits they are the same.