Story #7650
DAO for SystemMetadata changes the SystemMetadata.replicationPolicy
0%
Description
SystemMetadataDaoMetacatImpl (in d1_cn_common) sets replication_allowed to false in situations of a null ReplicationPolicy, even though the CN is not supposed to alter the ReplicationPolicy.
DataONE has historically taken the approach of opting into replicating content, instead of opting-out, so at least the default of false is in keeping with that. However, the DAO layer seems to be the wrong place to be applying business rules. It would be better to put in d1_synchronization logic. (and updateSystemMetadata).
Two issues are at play here:
1. should the semantics of a null replicationPolicy be "use the CN default behavior at the time of submission" or "I don't care" - allowing the CN to add or remove replicas at will."?
If the former, we need to persist a default ReplicationPolicy. If the latter, we need to remove the addition of a ReplicationPolicy, and potentially remove default polices based on MN versions of system metadata.
- should the DAO implemention apply the business rules about default values, or should it be refactored to d1_synchronization and updateSystemMEtadata?
Related issues
History
#1 Updated by Rob Nahf almost 9 years ago
- Tracker changed from Bug to Story
- Description updated (diff)
- Subject changed from DAOaccess for SystemMetadata changes the SystemMetadata.replicationPolicy to DAO for SystemMetadata changes the SystemMetadata.replicationPolicy
- Priority changed from Urgent to Normal
#2 Updated by Rob Nahf over 8 years ago
- Description updated (diff)
DataONE should continue to have "opt-in" semantics, and so it is proper for the CN to populate a default replication policy if none is provided, and set replication_allowed to false.
What is the impact of refactoring? maybe there's a good central place where "null defaults" can be set...
#3 Updated by Rob Nahf over 8 years ago
- Assignee set to Rob Nahf
#4 Updated by Chris Jones over 8 years ago
Just as a side note, the SystemMetadataDAOMetacatImpl, IIRC, was originally written for the d1_tidy process when we needed to clean up system metadata across CNs. Perhaps it was adopted into d1_cn_common, and some of the policy decisions that were meant for the tidy process were pulled in too, perhaps inadvertently.
#5 Updated by Robert Waltz over 8 years ago
- Target version changed from CCI-2.2.0 to Release Backlog
#6 Updated by Rob Nahf over 8 years ago
- Description updated (diff)
#7 Updated by Dave Vieglais almost 7 years ago
- Sprint set to Infrastructure backlog
#8 Updated by Dave Vieglais over 6 years ago
- Related to Story #8639: Replication performance is too slow to service demand added