-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add uuid format to STAC/Record id #18
base: main
Are you sure you want to change the base?
Conversation
I just noted an issue in the frontend form GUI, this would assign an UUID to each edited file, not just to new ones; might need to implement custom functionality in order to preserve existing ids but only allow UUIDs for new files. |
Issue in the GUI has been resolved, so ready to merge. |
Turns out this breaks the validation, since all the existing IDs would be invalid. Not sure how to proceed, to enforce UUID format for future entries, but still allow current entries 🤔. Any thoughts @m-mohr? In the GUI we solved by not enforcing an override, meaning if the id is empty, generate UUID, if it already includes a string, keep it... |
JSON Schema can't solve this for you. How should it know when an entry is new and when it's an old one? |
Exactly - so how are we going to solve ESA-EarthCODE/open-science-catalog-metadata#312? Not enforce it and hope that external contributions (not coming from the GUI) will do this correctly? Or turn off ajv validation in this case, so at least in the schema we have it noted, as a bit more of an incentive? Trying to understand what are our options in this case. |
In the past (with the builder) we just created slugs based on the title and then due to the id <-> filename relationship it was ensured that no duplicates exist. Is this still be enforced/done in the UI? Generally, I think themes, variables and eo-missions at least should still use slugs and we just need to ensure that those are unique, which we can ensure per type. In theory someone could create the same id for theme and variable, but is this really an issue? This would also somewhat filter out potential duplicates, which is not the case anymore with uuids. For primarily user-contributed content (products, projects, workflows, experiments), we could create a uuid as the likelyhood for conflicts is higher. There's no way to enforce this through JSON Schema or validation though unless we change all existing IDs to follow the existing schema. How many people are actually not using the UI? It could be enough to enforce it there and only enforce in validation that IDs don't conflict, but not necessarily that they need to be of format uuid. |
Alternate proposal: ESA-EarthCODE/open-science-catalog-metadata#312 (comment) |
Set default format of "uuid".
Closes ESA-EarthCODE/open-science-catalog-metadata#312