The default for the rate_limit column in the services and
services_history model is now set in the model, so we can remove the
default from the database.
Pivotal story: https://www.pivotaltracker.com/story/show/153992529
The API rate limit will be removed from the config and added to services
so that it is possible to change the rate_limit for individual services
in rare cases.
Pivotal story: https://www.pivotaltracker.com/story/show/153992529
There is no need for the extra column.
If a template does not have a default address set - they address will be blank.
Otherwise use the address of the service_letter_contact.
There will be another PR to do a db migration.
Template.service_letter_contact = blank if no service_letter_contacts for service ELSE use set Template.serivce_letter_contact_id = service default service_letter_contact
If is_letter_contact_blank then the user has set the letter contact block to be blank on purpose
ELSE IF is_letter_contact_blank is false THEN use the template default
IF template default is blank THEN the service_letter_contact is blank use the service default
- Added the boolean 'crown' column to services and services_history tables
- We populate this column in the same migration script by checking the
'organisation_type' of a service
This is text value of the sender_id, depending on the channel this will be a SMS sender, email reply to address or a letter contact block.
This is the first PR in a series to refactor how we send the "reply_to" the provider, eventually we can eliminate the notification_to_sms_sender and notification_to_email_to tables.
Removes "NOT VALID" mark from the notifications -> template_history
foreign key constraint by validating existing records.
From postgres docs:
> This form validates a foreign key or check constraint that was
> previously created as NOT VALID, by scanning the table to ensure there
> are no rows for which the constraint is not satisfied. Nothing happens
> if the constraint is already marked valid.
> Validation can be a long process on larger tables. The value of
> separating validation from initial creation is that you can defer
> validation to less busy times, or can be used to give additional time
> to correct pre-existing errors while preventing new errors. Note also
> that validation on its own does not prevent normal write commands
> against the table while it runs.
> Validation acquires only a SHARE UPDATE EXCLUSIVE lock on the table
> being altered. If the constraint is a foreign key then a ROW SHARE
> lock is also required on the table referenced by the constraint.
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.
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.
