Bug #5860
closedWhen morpho saves a network data package to local, the system metadata may contain id (obsoletes) which doesn't exist
0%
Description
Here are the steps to produce the bug:
1. Create a data package with data object and save it to the network. It contains:
resourceMap_foo.1, foo.1 and data.1
2. Update data.1 and save it to both network and local. It contains resourceMap-foo.2, foo.2 and data.2.
When we check the metadata for the resourceMap_foo.2, we found it has the <obsoletes>resourceMap_foo.1</obsoletes>. Actually the local doesn't have resourceMap_foo.1.
Same thing to the foo.2 and data.2.
Related issues
Updated by ben leinfelder almost 12 years ago
This is tricky. I know we decided a while back that we should manage the revision history separately for local vs. network objects, but in the old days when we used scope.docid.rev we implicitly considered revisions across their locations (so a newer version on the network does actually obsolete an older version locally even if it isn't yet saved locally).
I think we might have to manage revisions centrally so that we allow something on the network to obsolete something locally (and the other way around). There's another bug that might be related to this involving the search results: #5805
Updated by Jing Tao almost 12 years ago
Since the other way - saving locally first then saving both, works, we move this bug to 2.1
Updated by ben leinfelder almost 12 years ago
Jing and I talked about a related issue today and decided that we CAN leave the <obsoletes> values in local system metadata so that the revision chain does not get broken if we save a network file locally as a new revision and then save it back to the network after making multiple revisions locally.
Updated by Jing Tao almost 12 years ago
Add the code to set the obsoletes element in the system metadata and the revision manager even though the obsoleted id doesn't exist locally. This is only for the local saving.