Page Comparison

...

• 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. Tenant-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.

Process:

• Soft-delete:
  1. update the soft-delete flag in the original table, send events
  2. after events are processed, move the deleted record to the archive table
• Hard-delete: if the If the authority retention policy is set then, on schedule, the archive table should be cleaned by lastUpdatedDate field. A reasonable schedule frequency is once a day. The retention period for deleted records should be fetched from mod-settings. Then each job run should remove all deleted records, that are older than the retention period.
• a "delete" event should be sent to mod-source-record-storage to remove related source records. To enable consuming of "delete" events it is required to add an operation to the kafka message header and filter out other operations
if the retention policy for the tenant is set to never then no cleanup is requiredto NEVER_PURGE: should ignore the hard deletion part. This can be reached by disabling scheduled job.

Process:

Image Added

Open Questions