Preserve Old RELS-EXT during updates fails

[DiegoPino]

What is happening?

We are failing to preserve the old RELS-EXT because we implicitly create a new one when adding the CMODEL during an update process

FIX?

Upcoming.

#107

[wpwentzell]

Hi Diego,

Here is our experience:

We were unable to modify any datastreams or add additional datastreams during an update using the IMI. This behavior was consistent with all available RELS-EXT options for updates. Once we tried to update a child object the relationship to the parent object would break but not completely. So a child object would still exist but would no longer be visible under the parent. The only place on a parent that it could be seen is in the "Collection Usage Stats" on the "Overview" page of the "Manage" tab. This only holds true if the item was previously viewed before the update. The child is not visible under the "Collection" page under the "Manage" tab. So the parent child relationship is damaged but not completely destroyed as the updated child object does not show up in an orphan report.

[DiegoPino]

Hey @wpwentzell does this happened with or without #107?
Which of the many RELS EXT update options did you use during the update operation? There is actually one that does exactly that what you say: it removes all old RELS EXT except cmodel and cmode specific ones, so if the update operation was set on that setting and you did not setup the parent again during the workflow then you end with orphans.

Maybe we could add an option to revert versions of datastreams via IMI too. That would allow those objects to go back to its previous state by reverting rels-ext.

Let me know how i can help there

D

[wpwentzell]

Hello Diego,

My supervisor has added some documentation to the issues we are facing. It appears that regardless of the RELS-EXT behaviors selected at the time of update, the item's relationship to the directory it resides in changes so that it is no longer visible from within a directory.

Here is our documentation of the issues: https://docs.google.com/document/d/1OtfLSogx5UDKYciNS-0yokFe5ffC9ev5GYgWIMw-ufE/edit

[DiegoPino]

@wpwentzell following up on this since i can not reproduce. Wondering if the issue is that you are not running the patched version (see README.md) of islandora Batch? BY default islandora batch is quite limited and only ingest new Objects. We modified it to allow any operation to happen, including updates on existing objects. Also, our patch/branch allows for the same PID to exist in different Batch Sets. Please let me know, i can really dig deeper into this, but i can not reproduce the 500 error you are getting.

[wpwentzell]

Hello Diego. Some time later with an update: the patched Batch module initially seemed to fix the issue. But now, my supervisor notes that the issue has mysteriously returned. I will investigate this week and get back with you with what I find.

[DiegoPino]

Hi, yes please let me know. Also check the git log, maybe someone by mistake reverted to an older commit? New default branch has also a few improvements/new features Best El El mar, 19 de ene. de 2021 a la(s) 12:32, wpwentzell < [email protected]> escribió:

Hello Diego. Some time later with an update: the patched Batch module initially seemed to fix the issue. But now, my supervisor notes that the issue has mysteriously returned. I will investigate this week and get back with you with what I find. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABU7ZZ74Q4ZILPE7D5CXEB3S2W62RANCNFSM4IXUYNEA> .

-- Diego Pino Navarro Digital Repositories Developer Metropolitan New York Library Council (METRO)