anyone tried this out? <https://twitter.com/hnasr/...
# sqlz
zackster
05/14/2023, 12:38 PManyone tried this out? https://twitter.com/hnasr/status/1657569218609684480 https://github.com/0xShamil/ulid4j
zackster
05/14/2023, 4:55 PMa
aliaspooryorik
05/15/2023, 9:38 AM
interesting - I don't think any database engines support that natively for generating primary keys do they? (I know that's not specifically what you are asking)
a
Adam Cameron
05/15/2023, 1:41 PM
All of this seems to be based on a misunderstanding that UUIDs are random; most variants of UUID are not, and are - indeed - sequential (for a given generator, as there's also a physical component to them; usually derived from one of the generator's MAC addresses) for the most part).
This sounds like it's addressing a solved problem. I guess there's more to it, because it does seem to have some uptake.
If the impetus for doing this in Lucee is " BTREE indexes work way better with less random data" then it's perhaps not work that actually needs to be done. Possibly Lucee is using a version 4 UUID - which is the one which relies more on randomness than the other versions. Just.. use one of the non-random variants.
Is this something that anyone has asked for, or is it busywork?
Adam Cameron
05/15/2023, 2:03 PM
I also note the spec for this has only 40-bits of ordered information - only ordered to the millisecond - before dropping to random, whereas a UUID has 60-bits of ordered data (ordered to 100nanosecond intervals), and further sequence correction after that, if needed.
And presented as a string where DB-native UUIDs are integers, so I suspect more performant. Not that for almost anyone (and no-one using Lucee) that would matter.
z
zackster
05/15/2023, 4:53 PM4 Views