migrations/versions/0142_validate_constraints.py

"""

Revision ID: 0142_validate_constraint
Revises: 0141_remove_unused
Create Date: 2017-11-15 14:39:13.657666

"""
from alembic import op
from sqlalchemy.dialects import postgresql

revision = "0142_validate_constraint"
down_revision = "0141_remove_unused"


def upgrade():
    op.execute(
        'ALTER TABLE notifications VALIDATE CONSTRAINT "notifications_templates_history_fkey"'
    )
    op.execute(
        'ALTER TABLE notification_history VALIDATE CONSTRAINT "notification_history_templates_history_fkey"'
    )


def downgrade():
    pass
Validate notifcations.template_history foreign key constraints 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. 2017-11-15 14:48:50 +00:00			`"""`

			`Revision ID: 0142_validate_constraint`
			`Revises: 0141_remove_unused`
			`Create Date: 2017-11-15 14:39:13.657666`

			`"""`
			`from alembic import op`
			`from sqlalchemy.dialects import postgresql`

reformat 2023-08-29 14:54:30 -07:00			`revision = "0142_validate_constraint"`
			`down_revision = "0141_remove_unused"`
Validate notifcations.template_history foreign key constraints 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. 2017-11-15 14:48:50 +00:00

			`def upgrade():`
reformat 2023-08-29 14:54:30 -07:00			`op.execute(`
			`'ALTER TABLE notifications VALIDATE CONSTRAINT "notifications_templates_history_fkey"'`
			`)`
			`op.execute(`
			`'ALTER TABLE notification_history VALIDATE CONSTRAINT "notification_history_templates_history_fkey"'`
			`)`
Validate notifcations.template_history foreign key constraints 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. 2017-11-15 14:48:50 +00:00

			`def downgrade():`
			`pass`