✅ SEP 14: UUID collision checking
Status: Finished
Date: 2023-04-07
Commit: e521f96aa448b83f61e25b9f986e17456934ec15
> Implemented within the `ingest_documents()` function using a UUID prefix
> check. This will cause an abort if ever two 8 digit UUID prefixes are found to
> collide.
All my documents are christened with a unique identifier in the form of a Version 4 UUID). This is the canonical, unchangeable reference to a document and must therefore be absolutely guaranteed to be unique at all times.
The probability of UUID collisions occurring in a sufficiently random UUID implementation is vanishingly low. Still, it may be sensible to explore the possible issues that would arise from a collision and weigh that against the cost of mitigating that risk.
Further, since ✅ SEP 12: Reference documents by their URN/UUID was implemented on 2023-04-07, more and more documents will be referenced using the eight digit prefix of their UUID. This dramatically raises the risk of a collision wherever prefixes are used (though the risk remains fairly low).
Considerations
-
Given that I also use UUIDs to identify unpublished documents, consideration should be given to whether unpublished documents should be checked in the same way.
It should be noted though that this represents a lesser concern as any issue arising from a collision in my unpublished documents could be resolved manually without risk of changing a published resource.
-
RESOLVEDAs at 2023-04-06 it is still possible for a full UUID collision to go undetected. This would occur because theingest_documents()function does not check for uniqueness before writing to a UUID key.
