News for hackers. Stuff that matters.

A comment on Show HN: 128-bit, roughly-ordered, URL-safe UUIDs. Parent comment

Re:Show HN: 128-bit, roughly-ordered, URL-safe UUIDs by mgkimsal on Friday January 22, 2021 @07:16AM (#25871005)
I've been using ULID on a couple projects. In one case, we're trying to convert an existing project to use them, and... it's a bit of a pain, but it's not ULID's fault as much as just... changing primary keys all over the place is time consuming and not simple.

The biggest pushback (and it's not a terribly big one, imo) I've read on ULID is that the time portion is sold as 'sortable' but is 'only ms-level resolution'. Apparently the critics I was initially reading on ULID needed sub millisecond accuracy, and somehow thought this made ULIDs bad. Seemed a non-useful criticism, as needing that level of time granularity isn't a day to day issue for most people, but might be something to be aware of if the idea of overloading one field with multiple uses is a requirement you have.

[ Parent | on HN ]
Re:Show HN: 128-bit, roughly-ordered, URL-safe UUIDs by techdragon on Friday January 22, 2021 @07:50AM (#25871234)
If you’re an edge case you’re an edge case. It’s frustrating when people start assuming their use case is normal without any considerations of the wider world.

Sub millisecond precision sorting of high speed database inserts is hardly a normal requirement. At that point even the size of your transaction can matter (depending on the database) and you have to start asking questions like do I want ordering by the time the transaction starts or the time it ends? And if your loading existing data from other sources and care about date ordering you should just be using the a dedicated column with the database appropriate time/date time/time stamp field anyway.

[ Parent | on HN ]