Changes between Initial Version and Version 6 of Ticket #31653


Ignore:
Timestamp:
06/03/2020 02:03:59 PM (9 months ago)
Author:
Adam Johnson
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #31653

    • Property Cc Simon Charette added
    • Property Component changed from Migrations to contrib.postgres
    • Property Summary changed from PostgreSQL add constraints via NOT VALID / VALIDATE CONSTRAINT to Add PostgreSQL operations to add constraints via NOT VALID / VALIDATE CONSTRAINT
  • Ticket #31653 – Description

    initial v6  
    11If you read the ALTER TABLE PostgreSQL docs ( https://www.postgresql.org/docs/12/sql-altertable.html ) for `ADD CONSTRAINT`, you'll see that it supports the `NOT VALID` option. This prevents the constraint from being checked against all existing data, although it does affect all inserted/updated rows. Adding a constraint this way does not exclusively lock the whole table to check it. To promote it to valid, the `VALIDATE CONSTRAINT` syntax can be used. This allows a non-exclusive lock on the table to validate all existing rows. This two step techinque allows constraints to be added to very active tables without locking out concurrent access and thus inflicting downtime.
    22
    3 I suggest Django always use this form when adding foreign keys and check constraints.
     3I suggest `django.contrib.postgres` add custom operations for these commands, with appropriate documentation around using them in non-atomic migrations.
Back to Top