Bug #7371
A systemMetadata update that changes the formatID from DATA to METADATA or RESOURCE_MAP will not upload the object to the CN
0%
Description
With V2, systemMetadata.formatID is allowed to change. If the formatID changes from a DATA format to another one after the initial harvest, d1_sync doesn't have a cn method that will persist the object if the systemmetadata is already registered.
cn.create could be modified, but it might be better to define a new v2 API method (cn.refreshObject?)
Related issues
Associated revisions
History
#1 Updated by Rob Nahf over 8 years ago
- Related to Story #7364: update the sync logic for basic v1-v2 interoperability added
#2 Updated by Rob Nahf over 8 years ago
- Related to Task #3787: CN should detect changed sysmeta and resync objects when needed added
#3 Updated by Robert Waltz over 8 years ago
If systemMetadata is updated, CNCore.updateSystemMetadata, and Metacat notes that the formatId has changes, which in turn changes the content residing in or on Metacat, then Metacat should handle the change. Not d1_cn_service or cn synchronization.
Other systems, cn-rest-service or cn synchronization should not be responsible for deleting, creating or otherwise modifying the underlying storage mechanisms of Metacat.
any added method, such as'cn.refreshObject', would simply perform what metacat should do when CNCore.updateSystemMetadata is called.
#4 Updated by Matthew Jones over 8 years ago
This sounds like a private internal function of the CN service, not a public API method.
#5 Updated by Rob Nahf over 8 years ago
If we didn't already use restricted CN API methods to upload and persist content to the CN, I would tend to agree. However, responsibility for whether or not to upload and persist content on the CN exists wholly within d1_sync (and accomplished via API calls), so I think we do better to avoid spreading responsibility to other packages and end up with more than one component responsible for the same thing.
Currently, we use restricted CN API methods to persist new systemMetadata (cn.reigsterSystemMetadata), update systemMetadata (cn.updateSystemMetadata), and create new content (cn.create) on the CN. For v1 content, the cn.setAccessPolicy, cn.obsoletedBy, cn.archive methods are used. Within sync, there is robust logic for retrying content uploads.
#6 Updated by Rob Nahf over 8 years ago
- Target version changed from CCI-2.0.0 to Release Backlog
discussed in extra maintenance meeting today. Decided that since we have a "manual intervention" process, this is not a priority for V2.1. Moving to the release backlog.
We did not discuss throughly the issue of whether it should be an API method or otherwise.
Synchronization will create a log entry, however, when formatID changes and would require uploading the object to the CN.
