You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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
torecord
(withON UPDATE RESTRICT ON DELETE RESTRICT
). We probably don't wantON 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.
The text was updated successfully, but these errors were encountered: