...
...
Page Properties | ||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Executive Summary
LoC requires an authority deletion feature. The implementation should not have a negative impact on active records performance.
Requirements
Functional Requirements
- Allow the library to export deleted MARC authority records via API.
- Support providing deleted authority record UUIDs via API
- Support authority record purge configuration to be set to Never per tenant
Non-functional Requirements
...
- Same tablespace as the active table. Table name pattern
<original_table_name>_archive
- Trigger on delete should be implemented to move the record to the archive table.
- Domain events should be distinct for soft- and hard-delete.
- Update
lastUpdatedDate, updatedByUserId
in metadata. - Tenant-level retention policy should be provided through configuration parameters.
Process:
- Soft-delete: update of the flag, after all events are sent and processed, move deleted record to the archive table
- Hard-delete: on schedule the archive table should be cleaned by
lastUpdatedDate
fieldTenant-level configuration of the retention period for the deleted records should be kept in mod-settings. - The projected transaction volume might cause a big amount of records. To address that the API for listing of deleted records should support export in plain text format and json. Besides that it should provide filtering by date and pagination, to be able to fetch list of deleted records in chunks.
- If the authority retention policy is set to NEVER_PURGE: should ignore the hard deletion part. This can be reached by disabling scheduled job.
Process:
Open Questions
# | Question | Answer |
---|---|---|
1 | Do we have to implement an "undo" action for delete(restore record)? | Khalilah Gambrell : NO |
2 | Are performance requirements numbers for peak moments or is every week expected to have such a load? |