as stated here it is possible that there might be the same UUID being generated for two different Kirby 3 objects. Is there a planning or current implementation on what happens when this occurs? Having twice the same ID for something different can not just break things, e. g. return the wrong content, but also be problematic if it’s important from a legal perspective that the UUIDs are indeed unique and never return the wrong content. Maybe it would be good if Kirby 3 checks if the generated UUID is unique and if not, generate a new one as long as an unique one has been generated?
The concept and idea is clear to me. What I thought about is: Isn’t this just a pure mathematical, theoretical view on it without considering e. g. the real implementation details or how complex real randomizing in computer system is? In other words: Wouldn’t be the first time that this kind of stuff breaks on implementation or algorithm level.
//Edit: Just found the answer to this; it looks like it relies on a third party implementation for the UUID and doesn’t recalculate on conflicts.
Yes, it’s theoretical. But I think the chances that for the practical purposes we are using them for we would ever experience duplicates, are just as or even more theoretical. So I think we would introduce unnecessary overhead with checking for conflicts and recalculation. After all, we are dealing with a CMS here with a rather limited number of elements, not rocket science.
It’s a statistical problem. The probability is really really tiny, but of course this doesn’t mean that you couldn’t be unlucky and get duplicates.
However checking for duplicates is practically not possible. Kirby would need to open (and lock!) every single content file of the whole site. For large sites this process would be so slow that creating new pages or uploading new files would no longer be practical.