Story #7650
Updated by Rob Nahf almost 8 years ago
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 like a bad place to be applying business rules. 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.
2. should the DAO implemention apply the business rules about default values, or should it be refactored to d1_synchronization and updateSystemMEtadata?
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 like a bad place to be applying business rules. 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.
2. should the DAO implemention apply the business rules about default values, or should it be refactored to d1_synchronization and updateSystemMEtadata?
