Removes FileSet related objects when work deleted (#6334).

[bwatson78]

Fixes

Fixes #6334

Summary

Adds transaction triggers that removes FileSets' Hyrax::FileMetadata and AccessControl objects.

Guidance for testing, such as acceptance criteria or new user interface behaviors:

• Load sirenia (Add config for valkyrie fedora and "sirenia" compose file #6331)
• Open http://localhost:8081/fcrepo/rest/development and take note of number of objects present (clean install should have 2)
• Create monograph and reload the Fedora UI above. Take note of added number of objects (usually 6)
• Delete the monograph
• Reload the Fedora UI once more. The object total should return to the original number

Type of change (for release notes)

notes-valkyrie Valkyrie Progress

Detailed Description

Adds transaction triggers that removes FileSets' Hyrax::FileMetadata and AccessControl objects.

Changes proposed in this pull request:

• Override lib/hyrax/transactions/work_destroy.rb's #call to process private methods that find the Work's associated FileSets and remove the previously orphaned Hyrax::FileMetadata and AccessControl objects tie to them.

@samvera/hyrax-code-reviewers

[dlpierce]

The pattern for transactions/steps has been to put all of the actual work in a step and keep transactions contain only a list of steps to take, so this should be moved to a step.

I wonder if UpdateWorkMembers could be of use?

[bwatson78]

@dlpierce I've added my best attempt of rspec here. I tried to get a work with a fileset that contained a file with an associated FileMetadata object, but I couldn't get one going.

[dlpierce]

I tried this out on clean koppie and sirenia.

• I created a generic work with one file.
• Sirenia: Everything related to the work is cleared from fedora, although solr still has records for two FileMetadata objects.
• Koppie: Postgres still contains one FileSet object, solr has records for two FileMetadata objects and one FileSet

It looks like the steps do not actually remove the FileSet as it is now, so I'm curious how it was removed from Fedora

[bwatson78]

I forgot to check Koppie--apologies for that. When we last discussed the work deletion behavior, I commented how it appears the object created by the resource_factory that is sent to Fedora to delete the work included references to the associated FileSet. Looking for that now...

[bwatson78]

For the Solr objects--should I just kick off a full reindex?

[bwatson78]

The resource factory here creates a graph that references the FileSet when forming the object to send to the Fedora API. Apparently, the API takes that as a deletion dependency...I guess. But that's my best guess.

[bwatson78]

Should I reverse tactics and experiment with explictly deleting all FileSets attached to a Work before deleting the Work itself? See if that takes care of all of the FileSets' children without having to call all of the other steps?

[dlpierce]

The deletion dependency seems possible. The way I see it working is the destroy work steps should include a call to a step to destroy the FileSet, which then destroys its FileMetadata objects. I think the generic delete resource step can be used at each level to carry out the actual deletion? That way the number of places in code concerned with doing a given action is kept to a minimum.

[bwatson78]

Alrighty, I'll see how making a call to delete all FileSets before deleting the Work goes.

[bwatson78]

@dlpierce When attempting to call the Hyrax::Transactions::Container['file_set.destroy'] from within the same step I've been working on, I received an LDP::Gone error from this file: app/services/hyrax/listeners/member_cleanup_listener.rb. I realized that the transaction wasn't set up there, like it should be. That's why we still have orphans (and why work_resource.destroy deletes the FileSet--that is, at least for Fedora. I don't know why this doesn't work for PG yet.)

This "fix" doesn't fix everything, though. An ACL for the FileSet is still left behind. And, for some reason, Solr is left with the AdminSet and 2 FileMetadata objects (which are gone from Fedora.) I think I'll add a full reindex call into the same method I've already altered.

[bwatson78]

@dlpierce I've removed all of the errant objects (Solr and Fedora) on the Sirenia side. I've run out of time for today, so I couldn't get to Koppie testing or rspec. See you on Monday the 16th.

[bwatson78]

This should be ready for review. The Koppie side of thing is affected by the Work being removed before queried for its child members.