Skip to content
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

DOI modification check should be case-insensitive #31

Open
marksparkza opened this issue Jun 20, 2024 · 2 comments
Open

DOI modification check should be case-insensitive #31

marksparkza opened this issue Jun 20, 2024 · 2 comments

Comments

@marksparkza
Copy link
Member

marksparkza commented Jun 20, 2024

A change in case of a DOI should not trigger "The DOI has been published and cannot be modified" error. This happened recently (on dev) with a change in case of DOIs coming from the Observations DB.

For comparison, the DOI conflict check is case-insensitive. This prevents records from being created or updated and assigned a DOI that already belongs to another record but would otherwise pass the unique constraint due to being differently cased.

The published DOI modification check was probably left as case-sensitive because of the foreign key from published_record to record (with ON UPDATE RESTRICT ON DELETE RESTRICT). We probably don't want ON UPDATE CASCADE - this would defeat the 'immutability of published DOIs' that this table provides.

The published DOI modification check should be case-insensitive. However, we then need to also ignore DOI case changes in terms of updating record, otherwise we'd trigger the on update restriction in the DB layer and throw a 500 back to the client. This means never updating DOIs from data providers if they are just changing case. But DOIs are case-insensitive, so in principle this is not a problem.

Data providers might expect a DOI case change to propagate to a published record, but ultimately it's a policy decision for the ODP as to whether to publish DOIs in uppercase, lowercase, or not to care. Currently, we don't care, but this should be reviewed.

@marksparkza
Copy link
Member Author

The uniqueness constraints on record.doi and published_record.doi should perhaps be made case-insensitive. This would be strictly more correct from a DB perspective, but we'd still need the case-insensitive DOI checks in the API layer to prevent triggering DB update restrictions. And this would further cement the need for a policy on DOI case for publishing.

@marksparkza
Copy link
Member Author

Following discussion with the curation team, the decision is that it's not necessary to standardise DOI case for publishing. DOIs are officially case-insensitive, after all. A catalogue client is still free to makes its own decision regarding DOI rendering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant