First draft to purge high volume data on an hourly basis.

This makes the assumption that we do not need NotificationHistory, we will need to ensure that for HighVolumeServices we do not recalculate the stats tables, either in the reporting_tasks nor in the commands.
The strategy to migrate to using this code is still up for design.
We will need to consider:
 - how to purge the data, safely, efficiently.
 - ensure we get the counts right for the stats table, the ft_notification_status table is particularly tricky, because as a notification moves from created -> sending -> delivered the row counts change for each status type. One idea is that we only write the `delivered`, `temporary-failure` and `permanent-failure` status into the table.

This is not production ready but just a draft to get the conversation going.
I also have an idea to stop returning "todays" notification data for HighVolumeServices on the dashboards/usages (except platform_admin) until this code is ready.
This commit is contained in:
Rebecca Law
2020-03-20 09:34:07 +00:00
parent 3a61a84ca3
commit 4adab1afeb
5 changed files with 209 additions and 5 deletions

View File

@@ -2148,3 +2148,10 @@ class ServiceContactList(db.Model):
"created_at": created_at_in_bst.strftime("%Y-%m-%d %H:%M:%S"),
}
return contact_list
class HighVolumeService(db.Model):
# Service that we want to purge data for hourly
__tablename__ = 'high_volume_service'
service_id = db.Column(UUID(as_uuid=True), primary_key=True, unique=True, index=True, nullable=False)