3 ms·
As the article points out, this is only an issue with UUIDv1. They claim "However, it is what most applications use." but I have no idea how true this is. I was
by ekimekim 3y ago
As the article points out, this is only an issue with UUIDv1. They claim "However, it is what most applications use." but I have no idea how true this is. I was under the impression that the vast majority of UUID generators were v4 by default. For example:
Postgres only offers random uuid generation (https://www.postgresql.org/docs/15/functions-uuid.html https://www.postgresql.org/docs/15/functions-uuid.html).
The `uuidgen` CLI tool, at least for modern versions (I have not checked historically), says (from https://man7.org/linux/man-pages/man1/uuidgen.1.html https://man7.org/linux/man-pages/man1/uuidgen.1.html): "By default uuidgen will generate a random-based UUID if a high-quality random number generator is present." (later it lists /dev/random as such a generator, present on almost all systems)
What's an example of a system that generates v1 uuids by default?
- antonjs 3y agoIsn't the string comparison claim also wrong? Although plenty of UUIDs are passed as strings in eg JSON, I was under the impression that where performance really matters (like db indexes) they were stored and compared as 128 bit fields. To be fair, the points about word sizes and ordering make sense.
- wswope 3y ago> What's an example of a system that generates v1 uuids by default? MySQL. One of many reasons to avoid it.
- smaccona 3y agoDidn’t know this - true as of MySQL 8.X. I would say “shocking” if it wasn’t in keeping with a number of dubious decisions made over the years. We are using MySQL, but thankfully are generating UUIDs in our app layer. Kludgy, non-cryptographically-safe UUID4 implementation in MySQL: https://stackoverflow.com/a/32965744 https://stackoverflow.com/a/32965744