Rebecca Law 4adab1afeb 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.

2020-03-20 09:34:07 +00:00

..

app

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

2020-03-20 09:34:07 +00:00

__init__.py

Change variable name to make more descriptive

2020-02-20 15:48:15 +00:00

conftest.py

remove monkeypatch

2020-01-06 17:53:56 +00:00

test_all_queues_used.py

…