This resulted in an auto-detected migration that drops and recreates the
constraint for each FK, despite the effective constraint remaining the
same (e.g. FOREIGN KEY (`modified_by_id`) REFERENCES `common_user`
(`id`); )
The
[https://github.com/django/django/blob/1.8.5/django/db/migrations/autodetector.py#L848
autodetection] just compares the deconstruction.
The
[https://github.com/django/django/blob/1.8.5/django/db/backends/base/schema.py#L486
schema editor] drops the FK and recreates it.
It's not entirely clear to me which part needs to be changed - whether the
deconstruction should not include on_delete, or whether the autodetector
should discard on_delete from consideration, or whether the editor should
check for parameters that actually change the effective FK.
What is clear is that dropping and recreating FKs isn't a fast operation
on large databases, and it would be good to avoid where possible.
--
Ticket URL: <https://code.djangoproject.com/ticket/25614>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by jdunck):
Here's the [https://github.com/django/django/commit/b5784048e085e8d
commit] that introduced on_delete on ForeignKey.on_delete. Perhaps
Andrew recalls the rationale of adding it.
--
Ticket URL: <https://code.djangoproject.com/ticket/25614#comment:1>
Comment (by jdunck):
And now I've tracked it to #23288, but still think adding on_delete was
likely unneeded.
--
Ticket URL: <https://code.djangoproject.com/ticket/25614#comment:2>
* status: new => closed
* resolution: => duplicate
Comment:
Looks like a duplicate of #25253. We don't currently exclude any model
field attributes from deconstruct so that's unlikely to be the solution
unless we change the design decision around that.
--
Ticket URL: <https://code.djangoproject.com/ticket/25614#comment:3>