#36779: DeleteModel can lead to missing FK constraints
--------------------------------+--------------------------------------
Reporter: Jamie Cockburn | Owner: Vishy Algo
Type: Bug | Status: assigned
Component: Migrations | Version: 6.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+--------------------------------------
Comment (by Simon Charette):
This is due to the `DeleteModel` operation resuling in a `DROP TABLE
%(table)s CASCADE`
([https://github.com/django/django/blob/e726254a380f2a35a2fcf71143e96cb5987d8102/django/db/backends/base/schema.py#L89
source]).
There is documented risk in crafting your own migration but I don't think
it's fair to expect foreign key constraints to be implicitly dropped.
Given the recent decision to remove `CASCADE` from `RemoveField` on
PostgreSQL #35487 (2a5aca38bbb37f6e7590ac6e68912bfbefb17dae) which landed
in 6.0 I think it's worth accepting this ticket for
[https://forum.djangoproject.com/t/removefield-dropping-views-without-
notice/31409 the same arguments] around implicit deletion of references
(views and foreing key references).
FWIW I ran the full `schema` and `migrations` test suite on Postgres,
SQLite, and MySQL against the following patch
{{{#!diff
diff --git a/django/db/backends/base/schema.py
b/django/db/backends/base/schema.py
index 1f27d6a0d4..1742622683 100644
--- a/django/db/backends/base/schema.py
+++ b/django/db/backends/base/schema.py
@@ -86,7 +86,7 @@ class BaseDatabaseSchemaEditor:
sql_create_table = "CREATE TABLE %(table)s (%(definition)s)"
sql_rename_table = "ALTER TABLE %(old_table)s RENAME TO
%(new_table)s"
sql_retablespace_table = "ALTER TABLE %(table)s SET TABLESPACE
%(new_tablespace)s"
- sql_delete_table = "DROP TABLE %(table)s CASCADE"
+ sql_delete_table = "DROP TABLE %(table)s"
sql_create_column = "ALTER TABLE %(table)s ADD COLUMN %(column)s
%(definition)s"
sql_alter_column = "ALTER TABLE %(table)s %(changes)s"
}}}
and everything passed so I dug more and it seems the usage of `CASCADE`
comes from
[https://github.com/django/django/commit/8ba5bf31986fa746ecc81683c64999dcea4f8e0a
#diff-4c84fbb83165bd5643606b3712b80a88a7c235235a8b61981de5ca30cea8d0faR30
the very begining of the migrations framework] and was likely ported from
South which had a more rudementary way of tracking references between
models and might explain the usage of cascade.
--
Ticket URL: <https://code.djangoproject.com/ticket/36779#comment:2>
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/0107019afb0595c4-e6d6fe06-1b8a-40c9-98ef-4a63a88f370f-000000%40eu-central-1.amazonses.com.
