-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address issue #2882: Support for archiving/restoring relationships via packager #3328
base: main
Are you sure you want to change the base?
Conversation
This pull request introduces 6 alerts when merging c87f85b into 94e18cb - view on LGTM.com new alerts:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two general areas that should be addressed:
- Non-functional (code formatting) changes in a few places...avoid these so review can focus on the functionality (but stay within checkstyle guidelines)
- Need javadocs on any public methods (saw some missing on a new class, there may be others)
Test coverage could also be increased to cover "scope":
- When provided, it should be respected
- When not provided, it should obey the default behavior (which should be different from the test case for the above)
This pull request fixes 1 alert when merging d1e7dfd into 94e18cb - view on LGTM.com fixed alerts:
|
Related issues
Description
This includes relationship information in METS AIPs created by the packager. They are stored in both directions, and there is a dedicated portion of METS, a new structMap, with id "RELS", for holding relationship information. Virtual metadata is also retained, but alongside concrete metadata as it was before.
Usage
When this change is part of the DSpace code, exporting items with relationships will automatically be done. There are no separate options for export.
For imports, it is possible to specify a "scope", which describes the relationships to follow (to restore related items) for the restore operation. This is necessary because it will sometimes be required that two related items need to be restored. They cannot be restored independently because a) we assume the items must be fully restored in a single restore operation, and b) when an item effectively depends on another to exist (via a relationship to it), it must be part of the same restore operation.
Scope can be specified with -z, which defaults to '*', which means all relationships will be followed one level out. If any of the referred items do not exist in the repository, it attempts to restore them as long as they are directly related to the original item being restored (this is analogous to how the "recursive" option has historically worked when restoring collections).
Scope syntax is any number of the following, separated by commas:
Where:
REL_LABEL
is the relationship to follow (*
means all), and recursive, if present, means to follow it forever (loops are detected and avoided if present).Testing
The easiest way to see the feature in action is to do a manual packager export/import of two related items in your repository, which aren't related to anything else (to keep it simple).
You should see the new structMap sections. You can remove the items from DSpace and then restore them.
Some ITs have been added to exercise this functionality.