The check for aggregation was too broad and hence was adding together
totals based on template_id and not the unqiue combination of
template id, month and year.
- Added test to test for the failure
- Added check and a test to for template_id, mon and year matches
- Celery process name did not match the task
We have now:
- defaulted new services to start with this column set to `true`
- migrated all preexisting services[1] to have either `true` or `false` set
for this column
There is no way for a service to switch back from `true`/`false` to
`null`.
This means that we can safely enforce a non-nullable constraint on this
column now.
1. There is a little gotcha: the GOV.UK Notify service still relies on
the `sms_sender` column. It doesn’t have a row in the
`service_sms_senders` table. This means the previous migration
never changed this service’s value for `prefix_sms` from `null`. So
this commit also changes its value to `False`, so that the rest of
the migration, of the whole column, is possible.
The template name should be returned for the response and the user will
pick a year, so ths adds those two features to the
notifications/templates_usage/monthly endpoint and added some tests to
test the functionality.
Added a new endpoint which combines the usage of the stats table and the
data from the notifications tables, instead of using all the data from
the notification_history table. This should speed up the query times
and improve the page performance.
- Updated to make the stats create and update function transactional as
it actually wasn't committing the data to the table
- Added the get from the stats table
- Add a a method to combine the two results
- Added the endpoint
Removes notifications.template_id foreign key and replaces it with
a composite foreign key constraint to TemplateHistory using the
existing notification columns for template ID and template version.
Foreign key constraint is created as NOT VALID to avoid locking the
notifications table while postgres verifies that existing records
don't break the constraint. From postgres docs:
> If the constraint is marked NOT VALID, the potentially-lengthy initial
> check to verify that all rows in the table satisfy the constraint is
> skipped. The constraint will still be enforced against subsequent
> inserts or updates (that is, they'll fail unless there is a matching
> row in the referenced table, in the case of foreign keys; and they'll
> fail unless the new row matches the specified check constraints). But
> the database will not assume that the constraint holds for all rows
> in the table, until it is validated by using the VALIDATE CONSTRAINT
> option.
VALIDATE CONSTRAINT will be issued as a separate migration in a
follow-up PR.
Adds test for:
* checking the template version foreign key constraint
* checking that template changes don't affect existing notifications
* notification statistics aren't affected by different template versions
* notification stats always return the current template name
