Changing ForeignKey(on_delete=...) unnecessarily drops and recreates constraints

[Jeremy Dunck]

Recently I changed the on_delete attributes of many ForeignKeys on a MySQL database.

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 ​autodetection just compares the deconstruction.

The ​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.

[Jeremy Dunck]

Here's the ​commit that introduced on_delete on ForeignKey.on_delete. Perhaps Andrew recalls the rationale of adding it.

[Jeremy Dunck]

And now I've tracked it to #23288, but still think adding on_delete was likely unneeded.

[Tim Graham]

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.