22 ms·

According to the RFC, even v4 requires the version bits set. Is it worth it? Depends on what you want. For stuff like the original post, even an AUTOINCREMENT i

by epilys 5y ago

According to the RFC, even v4 requires the version bits set. Is it worth it? Depends on what you want. For stuff like the original post, even an AUTOINCREMENT integer primary key or even a title/slug text key would do just fine. For interfacing with external stuff that expects UUIDs it's mandatory for compliance. (I hope I didn't confuse many people by mentioning UUIDs)

rzzzt 5y ago
Suppose I want a universally unique identifier, which can be generated in a decentralized manner and there is a very small chance that someone else chooses to use the same number in the same system, resulting in a collision. I decide to use a pseudorandom generator for this purpose, picking numbers out of a sufficiently large space, where the chances of an undesired coincidence are precisely dialed in. What good rises out of including extra paperwork with each number, essentially saying "attention please, a random number", or "this is a timestamp, a monotonic counter and a MAC address", like if it was a newfangled smartphone? The RFC also says that there is no mechanism for validating a UUID, save for checking if its timestamp part is in the future, for versions that employ such a portion. Why can't any 128 bit value be accepted on the receiving end?
- bccdee 5y ago
  I suppose it further reduces the chance of a collision. If you're in a totally random space, there's always a chance someone will generate a collision if you wait long enough. But if you follow the timestamp and MAC address rules, then for a collision to happen it basically needs to be the same computer hitting the same number twice on the RNG within one second, which is less likely. But, since that only holds true if people follow the rules, it's worth standardizing on either v1 or v4, and so it's good to be able to distinguish between the two for validation purposes.

by epilys 5y ago

rzzzt 5y ago

Suppose I want a universally unique identifier, which can be generated in a decentralized manner and there is a very small chance that someone else chooses to use the same number in the same system, resulting in a collision. I decide to use a pseudorandom generator for this purpose, picking numbers out of a sufficiently large space, where the chances of an undesired coincidence are precisely dialed in. What good rises out of including extra paperwork with each number, essentially saying "attention please, a random number", or "this is a timestamp, a monotonic counter and a MAC address", like if it was a newfangled smartphone? The RFC also says that there is no mechanism for validating a UUID, save for checking if its timestamp part is in the future, for versions that employ such a portion. Why can't any 128 bit value be accepted on the receiving end?

bccdee 5y ago
I suppose it further reduces the chance of a collision. If you're in a totally random space, there's always a chance someone will generate a collision if you wait long enough. But if you follow the timestamp and MAC address rules, then for a collision to happen it basically needs to be the same computer hitting the same number twice on the RNG within one second, which is less likely. But, since that only holds true if people follow the rules, it's worth standardizing on either v1 or v4, and so it's good to be able to distinguish between the two for validation purposes.