Re:Type-safe, K-sortable, globally unique identifier inspire...
by dloreto on Wednesday June 28, 2023 @05:52PM
(#36513149)
The checksum idea is interesting. I'm considering whether it makes sense to add it as part of the TypeID spec.
[ Parent
| on HN ]
Re:Type-safe, K-sortable, globally unique identifier inspire...
by veec_cas_tant on Wednesday June 28, 2023 @08:38PM
(#36514813)
What value does the checksum provide? I think I'm missing something because I really don't see a benefit.
Re:Type-safe, K-sortable, globally unique identifier inspire...
by bumbledraven on Wednesday June 28, 2023 @11:13PM
(#36515895)
Checksums facilitate error detection. For typed UUIDs, checksums help detect errors introduced by changing the prefix/type or changing a “digit”.
Re:Type-safe, K-sortable, globally unique identifier inspire...
by diroussel on Sunday July 02, 2023 @04:13PM
(#36565196)
The benefit is that you can reject bad requests to an API more easily.
For one application I used a base 58 encoded value. Part of it was a truncated hmac, which I used like check digits. This meant I could validate IDs before hitting the DB. As an attacker or script kiddie could otherwise try a resource exhaustion attack.
So in the age of public internet faceing APIs and app urls, I think built in optional check digit support is a good idea.
Re:Type-safe, K-sortable, globally unique identifier inspire...
by veec_cas_tant on Monday July 03, 2023 @04:32AM
(#36570303)
I struggle to see how 10 bits of check data will help much. I guess if the extra bits aren’t persisted to storage it doesn’t hurt so why not?
Re:Type-safe, K-sortable, globally unique identifier inspire...
by diroussel on Monday July 03, 2023 @05:07PM
(#36578843)
Storage can get corrupted, columns can be truncated. For the applications I tend to touch correctness and the ability to detect errors and tamper are more important that a couple of bytes per row.
But every application and domain is different.