New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UUIDs should be unique, and must not be reused, even after deletion #1741
Comments
Two possible solutions to this:
|
Ahh... maybe we do need a delete flag on the schema... that way we seamlessly handle folk who've used !='draft' in db listings |
Using URIs as UUIDs was an idiot mistake and I wish I hadn't done it. At this point I don't care if UUIDs are ugly at all (although URLs should be readable), and I think ripping off the bandaid for a more robust internal system would be good. My position is that all the early stuff around federation should be fully ripped out. |
Hmmm.. of course, doing this check globally causes problems with users, who's handle forms part of their UUID - i.e, if I create user "marcus", delete him, it would not be possible to reuse "marcus"... which I guess might be desirable... Thoughts @benwerd? |
While trying to do this:
I encountered this error:
UUIDs should be Universally Unique, meaning that it should not be possible to create, delete, and recreate an entirely new object with a UUID of a previously deleted object.
This causes problems for membership lists for things like subscription groups, and potentially could be a security problem if a new ACL is created with the same UUID as an old one, since ACL membership is referenced by UUID.
The text was updated successfully, but these errors were encountered: