5 ms·

If you need lexicographically sortable uuids, you have a very different problem.

rco8786 8y ago
Different than what? Is wanting sortable unique IDs not a legitimate use case for some people?
exyi 8y ago
Well, in lot of cases you actually don't need that but it's a nice to have feature. The typical case being just giving IDs to some items you store in database - you can either give them UUIDs and enjoy that you can generate the ID in application and don't have to wait for database to create related entities to that. Or you choose sequential IDs generated by database, and you get that the IDs also have some meaning - you can for example sort by ID in your queries by default as it's roughly equivalent to creation date.
- int0x80 8y ago
  To me this is 'just' an optimization. If sorting by ID means 'sort by creation time' then you are just optimizing a timestamp in an entity. Overloading the ID, IOW. For the 'create the ID in the app' yes, but that is orthogonal to the ULID, AFAIK.
- jayd16 8y ago
  Whats wrong with actually using a creation date if that's what you actually want?
jmtulloss 8y ago
This is a "holy grail" problem in distributed systems (which this library doesn't solve on its own), but suggesting that it's not a valid problem to solve is confusing. Have you not encountered the use cases or do you prefer a different solution? With either of those objections spelled out this could be an interesting thread!
- int0x80 8y ago
  Any reference to this "holy grail" problem?
- mmirate3 8y ago
  Information-security can be oversimplified as one big "holy grail" problem unto itself - and when someone presents some software and proclaims it is "the" solution to that problem, but in fact has presented only a partial solution, then we call it "security theatre" and denounce it with extreme prejudice. I believe the comment you replied to, may be making an analogous argument here about distributed systems.

Different than what? Is wanting sortable unique IDs not a legitimate use case for some people?

exyi 8y ago

Well, in lot of cases you actually don't need that but it's a nice to have feature. The typical case being just giving IDs to some items you store in database - you can either give them UUIDs and enjoy that you can generate the ID in application and don't have to wait for database to create related entities to that. Or you choose sequential IDs generated by database, and you get that the IDs also have some meaning - you can for example sort by ID in your queries by default as it's roughly equivalent to creation date.

int0x80 8y ago
To me this is 'just' an optimization. If sorting by ID means 'sort by creation time' then you are just optimizing a timestamp in an entity. Overloading the ID, IOW. For the 'create the ID in the app' yes, but that is orthogonal to the ULID, AFAIK.
jayd16 8y ago
Whats wrong with actually using a creation date if that's what you actually want?

jmtulloss 8y ago

This is a "holy grail" problem in distributed systems (which this library doesn't solve on its own), but suggesting that it's not a valid problem to solve is confusing. Have you not encountered the use cases or do you prefer a different solution? With either of those objections spelled out this could be an interesting thread!

int0x80 8y ago
Any reference to this "holy grail" problem?
mmirate3 8y ago
Information-security can be oversimplified as one big "holy grail" problem unto itself - and when someone presents some software and proclaims it is "the" solution to that problem, but in fact has presented only a partial solution, then we call it "security theatre" and denounce it with extreme prejudice. I believe the comment you replied to, may be making an analogous argument here about distributed systems.