Hyrax is a Ruby on Rails Engine built by the Samvera community. Hyrax provides a foundation for creating many different digital repository applications.
Deleting a Valkyrie-based AdministrativeSet or collection doesn't delete the associated PermissionTemplate
Steps to reproduce the behavior in User Interface (UI)
We observed very slow performance in a staging instance of Comet, our staff-facing digital object management platform, which is a Hyrax / Valkyrie / Postgres application (Hyrax 5.0.1, Valkyrie 3.1.4, Postgres 14.
After some unsuccessful attempts to address the problem by writing more efficient queries, we eventually realized we had a very large number of PermissionTemplate records, many more than we had AdministrativeSet or PcdmCollection records. This combined with code in our seeds.rb to create an explosion in Sipity::WorkflowResponsibility records (> 80,000), as test AdministrativeSet records, including the default admin set, were deleted and recreated without the associated PermissionTemplate records being destroyed.
@marrus-sh noted that code exists to delete the associated PermissionTemplate when destroying an ActiveFedora-based traditional AdminSet, but there was no corresponding code for Valkyrie-based AdministrativeSets, which seems like it might be the root of the problem.
Acceptance Criteria/Expected Behavior
[ ] Deleting an AdministrativeSet or collection deletes the associated PermissionTemplate
Descriptive summary
Deleting a Valkyrie-based
AdministrativeSetor collection doesn't delete the associatedPermissionTemplateSteps to reproduce the behavior in User Interface (UI)
We observed very slow performance in a staging instance of Comet, our staff-facing digital object management platform, which is a Hyrax / Valkyrie / Postgres application (Hyrax 5.0.1, Valkyrie 3.1.4, Postgres 14.
After some unsuccessful attempts to address the problem by writing more efficient queries, we eventually realized we had a very large number of
PermissionTemplaterecords, many more than we hadAdministrativeSetorPcdmCollectionrecords. This combined with code in ourseeds.rbto create an explosion inSipity::WorkflowResponsibilityrecords (> 80,000), as testAdministrativeSetrecords, including the default admin set, were deleted and recreated without the associatedPermissionTemplaterecords being destroyed.@marrus-sh noted that code exists to delete the associated
PermissionTemplatewhen destroying an ActiveFedora-based traditionalAdminSet, but there was no corresponding code for Valkyrie-basedAdministrativeSets, which seems like it might be the root of the problem.Acceptance Criteria/Expected Behavior
AdministrativeSetor collection deletes the associatedPermissionTemplateRelated work
Issues and pull requests on our side: