Story #7650
Updated by Rob Nahf almost 9 years ago
SystemMetadataDaoMetacatImpl sets replication_allowed to false Retrieval from the CN systemMetadata RDBS tables adds "replicationAllowed = false" in situations of the O-R mapping layer (SystemMetadataDaoMetacatImpl), This is not a null ReplicationPolicy, even though field the CN is not supposed allowed to alter the ReplicationPolicy. change.
DataONE has historically taken It happens because ResultSet.getBoolean("...") returns false when the approach of opting into replicating content, instead of opting-out, so at least underlying value in the default of database is false is in keeping with that. However, the DAO layer seems to or null.
This could simply 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 viewing problem that disables replication for some objects, or a null replicationPolicy be "use storage problem where the CN default behavior at original value is lost if the time of submission" or "I don't care" - allowing "view" gets used as the CN basis for a system metadata update.
We need to add or remove replicas at will."?
If check the former, we need postgres database to persist a default ReplicationPolicy. see if replicationAllowed column has many null values.
Unit Tests did not catch this, and seemed to expressly allow it. (SystemMetadataDaoMetacatImplTestUtil line 569) If Business rules like this, if that is the latter, we need to remove case here, should not be applied at the addition of a ReplicationPolicy, data access layer, and potentially remove default polices based on MN versions of system metadata. especially not "on the way out".
2. we should the DAO implemention apply the business rules about default values, or should it be refactored using resultSet.wasNull() to d1_synchronization differentiate between null-defaulting-to-something cases and updateSystemMEtadata?
the real value being returned. see http://stackoverflow.com/questions/2920364/checking-for-a-null-int-value-from-a-java-resultset
DataONE has historically taken It happens because ResultSet.getBoolean("...") returns false when the approach of opting into replicating content, instead of opting-out, so at least underlying value in the default of database is false is in keeping with that. However, the DAO layer seems to or null.
This could simply 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 viewing problem that disables replication for some objects, or a null replicationPolicy be "use storage problem where the CN default behavior at original value is lost if the time of submission" or "I don't care" - allowing "view" gets used as the CN basis for a system metadata update.
We need to add or remove replicas at will."?
If check the former, we need postgres database to persist a default ReplicationPolicy. see if replicationAllowed column has many null values.
Unit Tests did not catch this, and seemed to expressly allow it. (SystemMetadataDaoMetacatImplTestUtil line 569) If Business rules like this, if that is the latter, we need to remove case here, should not be applied at the addition of a ReplicationPolicy, data access layer, and potentially remove default polices based on MN versions of system metadata. especially not "on the way out".
2. we should the DAO implemention apply the business rules about default values, or should it be refactored using resultSet.wasNull() to d1_synchronization differentiate between null-defaulting-to-something cases and updateSystemMEtadata?
the real value being returned. see http://stackoverflow.com/questions/2920364/checking-for-a-null-int-value-from-a-java-resultset
