#25618 closed Bug (fixed)
Django migration system breaks with unhelpful error message if south migrations accidentally retained
Reported by: | David Filipovic | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | 1.7 |
Severity: | Normal | Keywords: | migrations, south |
Cc: | django@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
For an app that contains both django and south type migrations, the migration system will become unable to perform any migration task for that app, and the error message will not be helpful at all (either "Application labels aren't unique, duplicates: x" - django 1.7, or "table x already exists" - django 1.8). This happens because the app is treated as both migrated and unmigrated at the same time.
To reproduce this error, you can clone the repo: django-south-bug. This repo contains a migrations directory with 2 south type migration in it.
Now run:
python manage.py makemigrations djsouth
followed by:
python manage.py migrate
What is of particular interest here is that the makemigrations command created the initial django migration without deleting the other numbered (south) migrations, thus putting the app into an erroneous state.
Additionally, it is worth noting that in this workflow, step 3 from upgrading-from-south was skipped, so essentially it is user error, however I believe that the error message should not be entirely unhelpful.
The patch attached can be applied to both django 1.7 and 1.8, since they are both affected by this. The patch will break the execution of the migration system at the graph construction phase and report with a helpful error message.
Attachments (2)
Change History (17)
by , 9 years ago
Attachment: | django-south-bug-fix.diff added |
---|
comment:1 by , 9 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:7 by , 9 years ago
Resolution: | fixed |
---|---|
Status: | closed → new |
The "fix" breaks django_extensions
and possibly a lot of other packages that have support for pre django 1.7 versions.
comment:8 by , 9 years ago
The problem is actually in the fact that django-extensions
is using the migrations
module to store south migrations and still claims to support Django 1.4 and later. However, since 1.7 the migrations
module was reserved for Django migrations, and even the last official release of South instructs developers to move south migrations to south_migrations
module.
So, in conclusion, django-extensions
never really fully supported Django 1.7+.
by , 9 years ago
Attachment: | django_style_migrations_fix.diff added |
---|
comment:9 by , 9 years ago
I'm not even sure if this should really be fixed on django's side, but I've created another patch, just in case.
This patch would make it so that in the case such as django-extensions
where south migrations
module was just left hanging around, against instructions to be moved, Django would just ignore those migrations.
I will create a pull request later, and let the core developers decide whether this should be addressed or not.
comment:10 by , 9 years ago
Cc: | added |
---|
comment:11 by , 9 years ago
@codingjoe, I've created a new pull request to address the problem you reported here.
comment:12 by , 9 years ago
FWIW django-extensions has fixed it internally (https://github.com/django-extensions/django-extensions/commit/dbabd69e48e682916e0ffdc7a3567f8fe148ddf3, https://github.com/django-extensions/django-extensions/blob/master/CHANGELOG.md#159), but I acknowledge that Django should expect other third-party apps not to toe the line.
It's a bit late to add this (in particular, 1.7 is end-of-life Dec. 1 and is only receiving security updates), but adding to 1.8/1.9 seems okay since you offered a patch, so I converted it to a pull request. For 1.10, I proposed to remove detection of south migrations.