#36645: PostgreSQL migration regression: `InternalError: cannot drop column id
of
table ... because other objects depend on it`
---------------------------------+----------------------------------------
Reporter: Adam Johnson | Owner: Adam Johnson
Type: Bug | Status: closed
Component: Migrations | Version: 6.0
Severity: Release blocker | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+----------------------------------------
Changes (by Adam Johnson):
* resolution: => wontfix
* status: assigned => closed
Comment:
Aha, this is indeed a feature, not a bug.
It turns out that the migrations on Django 5.2 would drop the foreign key
constraint, due to the cascade. Now PostgreSQL doesn't allow that,
preserving data integrity.
With my reproducer example, if I check the table *before* running the
final migration, I see:
{{{
# \d+ ratings_rating
Table
"public.ratings_rating"
Column | Type | Collation | Nullable | Default
| Storage | Compression | Stats target | Description
---------+--------+-----------+----------+----------------------------------+---------+-------------+--------------+-------------
id | bigint | | not null | generated by default as
identity | plain | | |
book_id | bigint | | not null |
| plain | | |
Indexes:
"ratings_rating_pkey" PRIMARY KEY, btree (id)
"ratings_rating_book_id_9d017958" btree (book_id)
Foreign-key constraints:
"ratings_rating_book_id_9d017958_fk_library_book_id" FOREIGN KEY
(book_id) REFERENCES library_book(id) DEFERRABLE INITIALLY DEFERRED
Access method: heap
}}}
Then if I run the migration:
{{{
$ ./manage.py migrate
Operations to perform:
Apply all migrations: library, ratings
Running migrations:
Applying library.0002_readable_remove_book_id_book_readable_ptr... OK
}}}
…then, boom! The foreign key constraint is gone:
{{{
# \d+ ratings_rating
Table
"public.ratings_rating"
Column | Type | Collation | Nullable | Default
| Storage | Compression | Stats target | Description
---------+--------+-----------+----------+----------------------------------+---------+-------------+--------------+-------------
id | bigint | | not null | generated by default as
identity | plain | | |
book_id | bigint | | not null |
| plain | | |
Indexes:
"ratings_rating_pkey" PRIMARY KEY, btree (id)
"ratings_rating_book_id_9d017958" btree (book_id)
Access method: heap
}}}
Moreover, I've run the same verification on my client's production app and
found missing foreign key constraints. Time to roll the sleeves up and get
to re-adding them…
So I think we can mark this as "working as intended".
One other note: I found that the migration pattern didn't work on SQLite
with Django 5.2. That makes sense because it never used `CASCADE`.
--
Ticket URL: <https://code.djangoproject.com/ticket/36645#comment:3>
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/01070199bf720a63-60affde6-6db5-4f32-89f5-9937b5b845c0-000000%40eu-central-1.amazonses.com.
