Skip to end of banner
Go to start of banner

MARC Authority Deletion

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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

Performance:

  • 10k weekly
  • 50k monthly 
  • Very rarely more than 100k (KG will confirm with LOC)

Data consistency:

  • There should be no invalid links to deleted authorities in instances
  • Authority statistics should be aligned after the authority record is deleted.

Data retention period:

  • Support authority record purge configuration to be set to Never per tenant

Assumptions

  • Authority record restoration is not planned in future releases

Baseline Architecture

The current implementation of authority record deletion consists of the following steps:

  1. "Soft-delete" Flag is updated to true
  2. Domain event regarding deleted records is sent through Kafka
  3. After events are sent and processed, records are physically deleted from the authority table

Target Architecture

The target solution for authority record deletion requires the support of export of deleted records, hence they should be persisted in the database and physically deleted only after the retention period elapses. This requires support of "soft" delete and "hard" delete operations. Soft-delete should be implemented as moving deleted records into the archive table in order to provide information on deleted records. The archive table also will provide minimal impact on the performance of active records.

The approach for the archive table:

  • Same tablespace as the active table.
  • 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 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 field

Open Questions

#QuestionAnswer
1

Do we have to implement an "undo" action for delete(restore record)?

Khalilah Gambrell : NO
2Are performance requirements numbers for peak moments or is every week expected to have such a load?


  • No labels