id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
28250	Ignore soft applied migrations in consistency check	Brian May		"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"	Cleanup/optimization	new	Migrations	dev	Normal			hertzog@… marten.knbk@… Ülgen Sarıkavak	Accepted	1	0	0	1	0	0