Anyone ever try encrypting a database ID (IE, a sequential int,) and use that as a public key?
IE, take a 32 or 64 bit int that's the primary key, encrypt it, and then use that as the public ID in a web application, URL, API, ect.
Goodbye integers, hello UUIDv7
271–280 of 376 posts
Re: Goodbye integers, hello UUIDv7
#272Is there some reason new versions of UUID keep appearing? It seems like the desired properties are never quite achieved so new ones appear later. Is there a table with UUID version across the top and characteristics down the side, so I can see the differences and pick one that fits my needs? That might also help to explain why there are so many variants.
Unless you have specific needs, the only type of UUID you should care about is v4. v1: mac address + time + random v4: completely random v5: input + seed (consistent, derived from input) v7: time + random (distributed sortable ids)
As someone who only cares about v4, I periodically wonder why don't I just use fully random 128-bit identifiers instead (without the version information).
Re: Goodbye integers, hello UUIDv7
#273This is great for internal distributed systems where having ordered keys is useful, however, it should probably be noted that these probably shouldn't be used as public identifiers (even though this will probably be the defacto standard and used publicly without thought). Having any information, specifically time information, leaking from your systems may or may not have unanticipated security or business implication…
Just randomise your clock.
/s
Persistent IDs are a security and information risk. If that's a concern, don't persist IDs.
Re: Goodbye integers, hello UUIDv7
#274IMO the benefit of UUIDs over integers is that they can be generated client-side without clashing. But you cannot trust timestamps generated by clients and therefore the order. So what is the benefit over UUID4?
For me the central benefit is that you can create them in a distributed manner and are not reliant on a central system as a single source of truth for creating your identifiers.
I can therefore easily generate a new UUID in a trusted backend service which just accepts the command received from the untrusted client and then forwards the request for asynchronous processing while returning the UUID to the client. This is a typical architecture and the only change is that I can now create UUIDs which may have performance benefits, depending on the data storage technology of my read models.
If you need to create the UUIDs on the client side to support specific requirements such as offline-first, then I would indeed consider adding some reconciliation which replaces the IDs provided by the client-side by new ones generated by a trusted component as soon as synchronizing takes place.
Re: Goodbye integers, hello UUIDv7
#275IMO the benefit of UUIDs over integers is that they can be generated client-side without clashing. But you cannot trust timestamps generated by clients and therefore the order. So what is the benefit over UUID4?
For me the central benefit is that you can create them in a distributed manner and are not reliant on a central system as a single source of truth for creating your identifiers. I can therefore easily generate a new UUID in a trusted backend service which just accepts the command received from the untrusted client and then forwards the request for asynchronous processing while returning the UUID to the client. This i…
In any case regardless of UUIDv4, v7 or any other format you should not allow the untrusted client to determine the real ID - as long as there is at least one trusted component in the architecture which would take over this role. This should help eliminate a whole set of possible security issues.
Re: Goodbye integers, hello UUIDv7
#276Is there some reason new versions of UUID keep appearing? It seems like the desired properties are never quite achieved so new ones appear later. Is there a table with UUID version across the top and characteristics down the side, so I can see the differences and pick one that fits my needs? That might also help to explain why there are so many variants.
Unless you have specific needs, the only type of UUID you should care about is v4. v1: mac address + time + random v4: completely random v5: input + seed (consistent, derived from input) v7: time + random (distributed sortable ids)
It would seem sequential keys for database performance is more than a 'specific' need.
Re: Goodbye integers, hello UUIDv7
#277Earlier quoted context omitted.
Unless you have specific needs, the only type of UUID you should care about is v4. v1: mac address + time + random v4: completely random v5: input + seed (consistent, derived from input) v7: time + random (distributed sortable ids)
As someone who only cares about v4, I periodically wonder why don't I just use fully random 128-bit identifiers instead (without the version information).
That'd be perfectly fine. You need to take some care to avoid duplicates or patterns though. Databases might not come with crypto-random out of the box but usually do have UUID support. Similarly, you need to use the crypto-random routines in your favorite standard library.
Depending on the implementation you still might have to worry about seeding issues. That's probably moot though since the UUID library would probably be compromised by something like that under the hood too.
Re: Goodbye integers, hello UUIDv7
#278Earlier quoted context omitted.
Second precision is too coarse for many (most?) use cases.
If you need more than second precision then millisecond doesn't get you much further. The fact that the epoch ends in 120 years is a bit more worrying, but is also just about non-critical enough that it will be ignored for at least the next century. Also, to all future historians of 2150, sorry about the mess, but yes we knew this was going to happen. Whatever it was.
> If you need more than second precision then millisecond doesn't get you much further.
It gets you precisely 100x further.
Re: Goodbye integers, hello UUIDv7
#279Speaking of RDBMs, how good are UUIDs when making joins and fetching a certain record?
Re: Goodbye integers, hello UUIDv7
#280Earlier quoted context omitted.
Unless you have specific needs, the only type of UUID you should care about is v4. v1: mac address + time + random v4: completely random v5: input + seed (consistent, derived from input) v7: time + random (distributed sortable ids)
As someone who only cares about v4, I periodically wonder why don't I just use fully random 128-bit identifiers instead (without the version information).
UUID v4 isn't large enough to prevent collisions, that is why segment.io created https://github.com/segmentio/ksuid which is 160bit vs the 128bit of a UUIDv4.