Sure, but that's not really the point is it? If you get a UUID you can store it as a UUID. If the UUID happens to come around as a v7 you get some better behavior in your database, and if it does not, then it does not but there is nothing you can do about.

▲

hnav 5 days ago | parent [-]

depends on the database, famously DynamoDB used to suffer from hotspotting when dealing with monotonically increasing keys

▲

the_mitsuhiko 5 days ago | parent [-]

You're missing the point here. You can always go from ordered to randomness. You cannot go from randomness to ordered. So by intentionally removing the useful properties of UUIDv7, you're taking away some external API consumers' hypothetical possibility to leverage benefits. If I know (as an API consumer) that I have a database that for whatever reason prefers evenly distributed primary keys or something similar, I can always accomplish that by hashing. I just can never go the other way.

▲

Lvl999Noob 5 days ago | parent | next [-]

Never use someone else's synthetic key as your primary key. If you want ordered keys, even if the API is giving out sequential integers, you should still use your own sequential IDs.

▲

avemg 5 days ago | parent | prev | next [-]

I take your point, but I think your hypothetical is a wonderful example of Hyrum's Law. And for that reason, if I was going to go to the trouble of mapping my internal v7 uuids into something more random for public consumption, then I'd be sure generate something that doesn't look like a uuid at all so nobody gets any funny ideas about what they can do with it.

▲

tart-lemonade 5 days ago | parent | prev [-]

Just to clarify, do you mean that UUIDv4 in general is worse, or just this 7->4 obfuscation?

	▲	the_mitsuhiko 5 days ago \| parent [-]
		I'm not saying anything about better or worse. I'm saying that UUID v4 by definition has high entropy and UUID v7 does not. You can always go from low to high entropy, but not the other way around.