#28250: migration depending on non-existing legacy migration
-----------------------------------------+------------------------
Reporter: Brian May | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.10
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 |
-----------------------------------------+------------------------
Hello,
As from http://bugs.debian.org/863267:
There exists a package (lava-server) that has a migration (called
`lava_scheduler_app.0001_initial`) with the following dependencies:
{{{
dependencies = [
...
('linaro_django_xmlrpc', '__first__'),
...
]
}}}
This migration was applied in prehistoric times, when Django 1.7 ruled the
earth. Unfortunately, at this stage, `linaro_django_xmlrpc` had no
migrations. Django 1.7 was fine with this. Everybody was happy.
Sometime after this, linaro_django_xmlrpc got a migration.
`0001_initial.py`. So we now have a migration installed, but its
dependencies are not installed. Or rather the database tables are there,
but the migration never has been registered in Django's table of
migrations.
Presumably Django 1.7 was happy with this, as Django 1.8 was also very
happy to deal with this. However Debian Jessie has Django 1.7 with a
version of linaro_django_xmlrpc before the migrations were introduced. Now
we are about to release Debian Stretch with Django 1.10 and the
linaro_django_xmlrpc migration.
So we have this jump from: Debian Jessie - Django 1.7 + migration not
included
to: Debian Stretch - Django 1.10 + migration included
Unfortunately Django 1.10 (and I am guessing also Django 1.11) is not so
agreeable. It immediately runs a check on all the prerequisites and aborts
with an error.
{{{
neil@jessie:~$ sudo lava-server manage migrate linaro_django_xmlrpc
--fake-initial
.....
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration
lava_scheduler_app.0001_initial is applied before its dependency
linaro_django_xmlrpc.0001_initial on database 'default'.
}}}
This means that the normal avenue of creating the required fake
transaction, does not work here, as Django 1.10 will not let us do this.
I seem to recall that mixing apps with migrations with apps without
migrations is somewhat complicated. Apologies if this particular situation
is documented somewhere (references would be good).
This issue was bought to light in the middle of a heated discussion on the
backports mailing list, with some people claiming that upgrading to Django
1.10 will delete user data. Hopefully I corrected this misconception. To
me it looks like no data is touched. However there is still a release
critical bug over Django 1.10, as the upgrade of this package fails.
Is this behaviour, as I described expected?
Is this behaviour a bug in Django? Or a feature?
Is there any work around possible to get Django 1.10 to process the
migrations?
Thanks
--
Ticket URL: <https://code.djangoproject.com/ticket/28250>
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/048.e8e4f386f924be54b400b4a591e27e29%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
