Switch from pk to uuid (except for users) #100
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
edan-bainglass
force-pushed
the
uuid
branch
4 times, most recently
from
1fd4554 to
2be5681
Compare
This was referenced Dec 25, 2025
edan-bainglass
force-pushed
the
uuid
branch
2 times, most recently
from
9a80c60 to
ca534bd
Compare
The implementation as in aiida-core.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on #99
This PR switches to using entity UUIDs for
get_entity_by_idendpoints. This does not apply to users, which don't have a UUID, and computers (for some reason). For now, these use PKs (as was done in the old RESTAPI).Peripheral change warning!!!
I also in this PR make error handling a bit more uniform across endpoints. However, I'm wondering if guarding against general
Exceptionerrors, raising code 500 (internal errors), is wise. I'm thinking we should allow these errors through, so that we can later guard against the actual specific errors. These are hard to see when all you get is the single-line error message (no traceback). But then the traceback may be to frighting for the client. Anyhow, keeping them in for now. @eimrek good to get your thoughts on this.