[Django] #31444: ForeignKey migrations without database changes shouldn't touch the database

11 views
Skip to first unread message

Django

unread,
Apr 9, 2020, 8:48:45 AM4/9/20
to django-...@googlegroups.com
#31444: ForeignKey migrations without database changes shouldn't touch the database
--------------------------------------+------------------------
Reporter: Peter Law | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 2.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
--------------------------------------+------------------------
If you have a model like this:

{{{#!python
class Thing(models.Model):
user = models.ForeignKey('auth.User', related_name='+')
}}}

And you then decide to change the related name, like so:

{{{#!python
class Thing(models.Model):
user = models.ForeignKey('auth.User', related_name='things')
}}}

Then Django will create a migration for this change. I understand why the
migration is present (all fine so far).

At least for Postgres (I've not tested elsewhere), when Django runs the
migration it will end up dropping and re-adding the foreign key (which
involves locking the table and having the database revalidate the
ForeignKey) but nothing else.
In a production system this is at best inconvenient and at worst can
significantly impact site performance for the duration of the migration
(or force you to take the site offline to run the migration).

Ideally Django would detect that nothing needs to be done to the database
for this migration and not emit any SQL for this migration.

There might be a general question here about why the foreign key is being
dropped and re-created (and if we can avoid that, that would be even
better), though I'd be happy for now with a fix just for the case of a no-
op.

--
Ticket URL: <https://code.djangoproject.com/ticket/31444>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Apr 9, 2020, 12:51:09 PM4/9/20
to django-...@googlegroups.com
#31444: ForeignKey migrations without database changes shouldn't touch the database
----------------------------+--------------------------------------

Reporter: Peter Law | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 2.2
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):

> At least for Postgres (I've not tested elsewhere), when Django runs the
migration it will end up dropping and re-adding the foreign key (which
involves locking the table and having the database revalidate the
ForeignKey) but nothing else.
> In a production system this is at best inconvenient and at worst can
significantly impact site performance for the duration of the migration
(or force you to take the site offline to run the migration).

Pretty sure this is solved in recent versions of Django, against which
version did you reproduce?

--
Ticket URL: <https://code.djangoproject.com/ticket/31444#comment:1>

Django

unread,
Apr 9, 2020, 1:11:08 PM4/9/20
to django-...@googlegroups.com
#31444: ForeignKey migrations without database changes shouldn't touch the database
----------------------------+--------------------------------------

Reporter: Peter Law | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 2.2
Severity: Normal | Resolution: needsinfo

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 Simon Charette):

* status: new => closed
* resolution: => needsinfo


Comment:

I couldn't reproduce on the latest point releases of Django 1.11, 2.0,
2.1, 2.2, 3.0, and master so this has been fixed for a long time. Please
reopen if you can provide more details about how to reproduce and upgrade
to 2.2 or 3.0 if you're still using an unsupported version.

--
Ticket URL: <https://code.djangoproject.com/ticket/31444#comment:2>

Reply all
Reply to author
Forward
0 new messages