#25253: MySQL migrations drop & recreate constraints unnecessarily when changing
attributes that don't affect the schema
--------------------------------------+------------------------------------
     Reporter:  Thomas Recouvreux     |                    Owner:  Shun Yu
         Type:  Cleanup/optimization  |                   Status:  assigned
    Component:  Migrations            |                  Version:  1.8
     Severity:  Normal                |               Resolution:
     Keywords:  migrations m2m mysql  |             Triage Stage:  Accepted
    Has patch:  0                     |      Needs documentation:  0
  Needs tests:  0                     |  Patch needs improvement:  0
Easy pickings:  0                     |                    UI/UX:  0
--------------------------------------+------------------------------------

Comment (by israel-tk):

 We had this problem with Postgres and Django 1.11 when deleting a not-null
 constraint in a ForeignKey field (adding null=True to a field). Instead of
 just dropping the not-null constraint which is a safe database operation,
 it first dropped the ForeignKey constraint, then dropped the not-null
 constraint, and last re-created the ForeignKey constraint (3 statements).

 Re-creating ForeignKey constraints locks tables and can generate downtime.
 Since we cannot afford the downtime we used a
 [https://docs.djangoproject.com/en/2.1/ref/migration-operations/#runsql
 RunSQL] migration operation with `state_operations` as a **workaround**:

 {{{
 migrations.RunSQL(
            """--
            -- Alter field trip on payment
            --
            ALTER TABLE "app_payment" ALTER COLUMN "trip_id" DROP NOT NULL;
            """,
            state_operations=[
                migrations.AlterField(
                    model_name='payment',
                    name='trip',
                    field=models.ForeignKey(blank=True, null=True,
 on_delete=django.db.models.deletion.PROTECT,
                                            related_name='payments',
 to='app.Trip'),
                ),
            ])
 }}}

 This way we only apply the SQL we want and Django won't complain about the
 migration state not matching the current model. :)

-- 
Ticket URL: <https://code.djangoproject.com/ticket/25253#comment:15>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.63ffc7e38421f28440deb0d822c12523%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to