Opened 5 years ago

Closed 5 years ago

#22275 closed Bug (fixed)

unique_together with foreign keys fails migration

Reported by: Ryan Hiebert Owned by: Anton Baklanov
Component: Migrations Version: master
Severity: Release blocker Keywords:
Cc: antonbaklanov@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no


When unique_together includes foreign keys, sometimes those fields are added in separate migrations. (why?) However, unique_together remains in the initial migration, before the field referenced in unique_together is created. Adding the unique_together constraint then fails.

Attachments (1) (900 bytes) - added by Ryan Hiebert 5 years ago.
Shell script that demonstrates unique_together issue

Download all attachments as: .zip

Change History (7)

Changed 5 years ago by Ryan Hiebert

Attachment: added

Shell script that demonstrates unique_together issue

comment:1 Changed 5 years ago by Ryan Hiebert

I also have a repository on Github that has a demonstration of the problem: The master branch demonstrates the problem. The syncdb branch shows that forcing syncdb behavior makes it work, and the late-unique branch demonstrates that waiting until after creating the initial migration to add the unique_together constraint is a work-around.

comment:2 Changed 5 years ago by Baptiste Mispelon

Severity: NormalRelease blocker
Triage Stage: UnreviewedAccepted
Type: UncategorizedBug


The provided models work on 1.6 (with syncdb) but indeed they fail on master (makemigrations work but migrate fails with the following traceback:

Traceback (most recent call last):
  File "", line 10, in <module>
  File "./django/core/management/", line 427, in execute_from_command_line
  File "./django/core/management/", line 419, in execute
  File "./django/core/management/", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "./django/core/management/", line 337, in execute
    output = self.handle(*args, **options)
  File "./django/core/management/commands/", line 145, in handle
    executor.migrate(targets, plan, fake=options.get("fake", False))
  File "./django/db/migrations/", line 60, in migrate
    self.apply_migration(migration, fake=fake)
  File "./django/db/migrations/", line 94, in apply_migration
    migration.apply(project_state, schema_editor)
  File "./django/db/migrations/", line 97, in apply
    operation.database_forwards(self.app_label, schema_editor, project_state, new_state)
  File "./django/db/migrations/operations/", line 28, in database_forwards
  File "./django/db/backends/", line 244, in create_model
    columns = [model._meta.get_field_by_name(field)[0].column for field in fields]
  File "./django/db/backends/", line 244, in <listcomp>
    columns = [model._meta.get_field_by_name(field)[0].column for field in fields]
  File "./django/db/models/", line 419, in get_field_by_name
    % (self.object_name, name))
django.db.models.fields.FieldDoesNotExist: Rabbit has no field named 'parent'

I'm bumping the severity to release blocker since it's a regression.

Thanks for catching this.

comment:3 Changed 5 years ago by Anton Baklanov

Cc: antonbaklanov@… added
Owner: changed from nobody to Anton Baklanov
Status: newassigned

Similar issue. I'm working on test+patch here now.

comment:4 Changed 5 years ago by Anton Baklanov

Has patch: set
Patch needs improvement: set

basic test + naive patch

I'm not opening a pull request for this ticket now since I would like to spend some extra time here.

  • This ticket needs more robust test cases
  • Currently patch moves all unique_together operations to second migration without making any differences whether all required fields have been created already or not. I decided to do it in this way since _detect_changes is a bit over complicated (in my opinion) to handle detection if particular unique_together good enough to be in first migration or it should wait for the next one, as it is done for foreign keys.

I will look into _detect_changes's code tomorrow one more time to see if it's possible to 'fix' this. Though I'm not completely sure this behavior needs any fixing.

comment:5 Changed 5 years ago by Andrew Godwin

It looks good enough to me; the optimisation of where to put it can be addressed along with the same optimisation for ForeignKeys (it currently errs a bit on the "splitting up" side), but in the interest of getting the beta out I'm committing it right now, as it fixes the bug.

comment:6 Changed 5 years ago by Andrew Godwin <andrew@…>

Resolution: fixed
Status: assignedclosed

In 81f5408c7a16b8c79053950f05fe7a873506ca55:

Fixed #22275: unique_together broken if ForeignKey split into new file.

Thanks to bak1an for the patch.

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