Here's a list of things that could happen during a restore operation. In the interests of thoroughness, I've listed things that should be normal in addition to error conditions. I think we should look at all of them to ensure we haven't missed anything.
To save typing I've used BDS to mean Backup Data Set and DM for Device's Device Model (as expressed by NcClassManager).
(Side question: Does the BDS include the NcClassManager and if so, what trait does it have?)
(Unlike IS-12, it seems that the primary way of identifying an object is via its role path but this does require use of oids. Therefore it seems like there should be a mapping process between the BDS set of oids and those in use on the device. If so, we need to describe that.)
The scenarios: What do we set in NcMethodResultObjectPropertiesSetValidation and/or NcObjectPropertiesSetValidation when...
The BDS Vendor fingerprint is not compatible with the Device?
The BDS includes a property in an NcObject the Device doesn't know about?
The BDS is missing an optional DM property?
The BDS is missing a mandatory DM property?
The BDS has a property that is read-only?
The type of a BDS property differs from the type in the DM?
The traits of a BDS property differs from what the device thinks they should be?
The value in the BDS is out of range?
A property is a struct and the BDS has a field with a name not in the DM?
A property is a struct and the BDS has a field with type that is different to that in the DM?
A property is a struct and the BDS is missing a field that is optional?
A property is a struct and the BDS is missing a field that is mandatory?
The BDS has an NcObject with a role path that isn't listed in any NcBlock in the BDS? (Maybe a result of editing)
The BDS lists a role in an NcBlock but there is no NcObject with that role path in the BDS or on the Device?
The BDS lists a role in an NcBlock but there is no NcObject with that role path in the BDS but there is one on the Device?
The BDS lists a role in an NcBlock but there is no NcObject with that role path on the Device but there is one in the BDS?
The BDS lists more NcWorkers in a block than the Device can support?
The BDS lists an oid that the Device has but the role names differ?
Two NcBlocks list the same oid?
Two NcObjects have the same oid?
Two instances of NcObjectPropertiesHolder have the same role path?
An NcBlock in the BDS lists an oid that is also listed in a NcBlock on the Device that has a different purpose?
Multiple instances of the same manager are present in the BDS?
Other comments:
It would be nice if NcMethodResultObjectPropertiesSetValidation included an overallStatus field
Do attempts to write to read-only properties create an NcPropertyRestoreException?
Should NcPropertyRestoreException have a 'severity' field (e.g. 'info' vs 'error')
NcRestoreValidationStatus is per NcObject - How do we deal with properties that are OK
isReadOnly in NcPropertyValueHolder shouldn't be nullable (unless null can be represented as absent)
Here's a list of things that could happen during a restore operation. In the interests of thoroughness, I've listed things that should be normal in addition to error conditions. I think we should look at all of them to ensure we haven't missed anything.
To save typing I've used BDS to mean Backup Data Set and DM for Device's Device Model (as expressed by NcClassManager).
(Side question: Does the BDS include the NcClassManager and if so, what trait does it have?)
(Unlike IS-12, it seems that the primary way of identifying an object is via its role path but this does require use of oids. Therefore it seems like there should be a mapping process between the BDS set of oids and those in use on the device. If so, we need to describe that.)
The scenarios: What do we set in NcMethodResultObjectPropertiesSetValidation and/or NcObjectPropertiesSetValidation when...
The BDS Vendor fingerprint is not compatible with the Device?
The BDS includes a property in an NcObject the Device doesn't know about?
The BDS is missing an optional DM property?
The BDS is missing a mandatory DM property?
The BDS has a property that is read-only?
The type of a BDS property differs from the type in the DM?
The traits of a BDS property differs from what the device thinks they should be?
The value in the BDS is out of range?
A property is a struct and the BDS has a field with a name not in the DM?
A property is a struct and the BDS has a field with type that is different to that in the DM?
A property is a struct and the BDS is missing a field that is optional?
A property is a struct and the BDS is missing a field that is mandatory?
The BDS has an NcObject with a role path that isn't listed in any NcBlock in the BDS? (Maybe a result of editing)
The BDS lists a role in an NcBlock but there is no NcObject with that role path in the BDS or on the Device?
The BDS lists a role in an NcBlock but there is no NcObject with that role path in the BDS but there is one on the Device?
The BDS lists a role in an NcBlock but there is no NcObject with that role path on the Device but there is one in the BDS?
The BDS lists more NcWorkers in a block than the Device can support?
The BDS lists an oid that the Device has but the role names differ?
Two NcBlocks list the same oid?
Two NcObjects have the same oid?
Two instances of NcObjectPropertiesHolder have the same role path?
An NcBlock in the BDS lists an oid that is also listed in a NcBlock on the Device that has a different purpose?
Multiple instances of the same manager are present in the BDS?
Other comments:
It would be nice if NcMethodResultObjectPropertiesSetValidation included an overallStatus field
Do attempts to write to read-only properties create an NcPropertyRestoreException?
Should NcPropertyRestoreException have a 'severity' field (e.g. 'info' vs 'error')
NcRestoreValidationStatus is per NcObject - How do we deal with properties that are OK
isReadOnly in NcPropertyValueHolder shouldn't be nullable (unless null can be represented as absent)