#37034: Improve writing migrations how-to add through field on a ManyToManyField
-------------------------------------+-------------------------------------
               Reporter:  Clifford   |          Owner:  Clifford Gama
  Gama                               |
                   Type:  Bug        |         Status:  assigned
              Component:             |        Version:  dev
  Documentation                      |       Keywords:  migrations,
               Severity:  Normal     |  ManyToManyField, through
           Triage Stage:             |      Has patch:  0
  Unreviewed                         |
    Needs documentation:  0          |    Needs tests:  0
Patch needs improvement:  0          |  Easy pickings:  0
                  UI/UX:  0          |
-------------------------------------+-------------------------------------
 1. Inaccurate description of how Django handles this change: The section
 states that "the default migration will delete the existing table and
 create a new one". This is not accurate. Django
 
[https://github.com/django/django/blob/d61f33f03b3177afdf1d76153014bad4107b1224/django/db/backends/base/schema.py#L894
 refuses to apply a migration] when `through=` is added/changed on an
 existing `ManyToManyField`.

 2. The through model example does not accurately reflect the database: The
 current example uses `on_delete=DO_NOTHING` and `models.UniqueConstraint`,
 whereas Django's auto-generated through tables use `CASCADE` and
 `unique_together`. In other words, future model states will not bear a
 correct representation of what's in the db.

 3. The example can be simplified by setting `Meta.db_table` on the new
 through model to match the existing table name, eliminating the need for a
 `RunSQL` rename operation.

 The section also suggests using `sqlmigrate` or `dbshell` to find the
 existing table name, which is indirect. The simplest approach is to
 inspect `field.through._meta.db_table` before modifying the field.

 Incidentally for the case where db_table remains the same, #36803 may
 allow us to suggest a simpler alternative in the docs, one that does not
 need to use `SeparateDatabaseAndState`.
-- 
Ticket URL: <https://code.djangoproject.com/ticket/37034>
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 view this discussion visit 
https://groups.google.com/d/msgid/django-updates/0107019d8b9a3938-21ed26f9-4366-448a-b2a4-dcdb9cc95dce-000000%40eu-central-1.amazonses.com.

Reply via email to