Opened 10 years ago

Last modified 10 years ago

#24447 closed Bug

Migrations do not execute create_fk_sql() when adding a foreign key to a field — at Initial Version

Reported by: Jean-Louis Fuchs Owned by: nobody
Component: Migrations Version: 1.7
Severity: Normal Keywords:
Cc: Markus Holtermann Triage Stage: Ready for checkin
Has patch: yes Needs documentation: yes
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

Migrations failed when introducing foreign keys on existing fields.

Pull request: https://github.com/django/django/pull/4235
Branch with fix: https://github.com/ganwell/django/tree/master_missing_create_fk_sql
Branch with unittest but no fix: https://github.com/ganwell/django/tree/master_missing_create_fk_sql_fail

Consider following model:

class ForeignKeyTest(models.Model):
    id = models.AutoField(primary_key=True)
    customer = models.IntegerField()

class Customer(models.Model):
    id = models.AutoField(primary_key=True)

Then it gets migrated to this:

class ForeignKeyTest(models.Model):
    id = models.AutoField(primary_key=True)
    customer = models.ForeignKey('Customer')

class Customer(models.Model):
    id = models.AutoField(primary_key=True)

The second migration won't create the foreign key. This does not fail with sqlite! Because these migrations are handled differently. It will fail with MySQL and probably Postgres too. I wrote a unittest and tested it with MySQL: master_missing_create_fk_sql_fail fails and master_missing_create_fk_sql is ok.

The code didn't detect this case - if old_field.rel doesn't exist alter_field() must always create the foreign key and ONLY if .rel exists it must check .db_constraint, too. Since no .rel also means there was no foreign key before.

I will of course redo the pull request to get clean history. I also fixed this in 1.7.

Change History (0)

Note: See TracTickets for help on using tickets.
Back to Top