Page Properties | ||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Executive Summary
LoC requires an authority deletion feature. The implementation should not have a negative impact on active records performance.
...
- 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 the soft-delete flag in the original table, send events
- after events are processed, move the deleted record to the archive table
- Hard-delete:
- if the retention policy is set then, on schedule the archive table should be cleaned by
lastUpdatedDate
field if the retention policy for the tenant is set to - 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.
never
then no clean up is requiredTenant-level configuration of the retention period for the deleted records should be kept in mod-settings. 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? |