On Fri, 26 May 2017 18:56:04 +1000 Brian May <b...@debian.org> wrote:
> Neil Williams <codeh...@debian.org> writes:
>
> > django.db.migrations.exceptions.InconsistentMigrationHistory:
> > Migration lava_scheduler_app.0001_initial is applied before its
> > dependency linaro_django_xmlrpc.0001_initial on database
> > 'default'.
>
> Ok, I see what is going on now. Untested theory at the moment, but it
> fits the symptoms.
>
> ./lava_scheduler_app/migrations/0001_initial.py contains:
>
> dependencies = [
> ('auth', '0001_initial'),
> migrations.swappable_dependency(settings.AUTH_USER_MODEL),
> ('linaro_django_xmlrpc', '__first__'),
> ('dashboard_app', '__first__'),
> ]
Again, I also spotted this and thought it was the source. However,
changing this causes the migration to fail with 1.10 as there are
objects in this model which must be applied before
lava_scheduler_app/0001_initial will complete. e.g. the AuthToken
object is referred to directly in lava_scheduler_app/0001_initial and
this is defined by linaro_django_xmlrpc
I tried a few simplistic edits of those migration files on a test
instance, the migrations still fail to apply.
>
> My reading of this is that this means this migration depends on the
> first migration from 'linaro_django_xmlrpc' to be already
> applied. However on Jessie, 'linaro_django_xmlrpc' has no
> migrations. Hence I suspect whatever version of Django that installed
> this migration to be buggy, because it didn't check the dependencies
> could be satisfied. Or maybe this was considered OK at the time.
7/9 Add initial Django migrations
From a25d49c6c96217011fead69b675e281b6e5b8fc5 Mon Sep 17 00:00:00
2001
From: Raphaël Hertzog <hert...@debian.org> Date: Tue, 9 Sep
2014 07:20:56 +0000
https://git.linaro.org/lava/lava-server.git/commit/?id=9e5595adae2b2ea6fc7e19820356ca1bd098110c
> This migration is already applied when we come to do the new
> migrations for Django 1.8 or Django 1.10
>
> Django 1.8 doesn't care that the first migration for
> 'linaro_django_xmlrpc' hasn't been applied yet. As a result, it can
> fake the migration and everyone is happy.
>
> Django 1.10 does care. It says the database is broken because the
> prerequisite for this migration was never applied. It does this check
> before applying any migrations.
>
> I don't know for sure what is correct behaviour here.
Changing existing migration files *after* user data has been created is
likely to cause data loss.
> However I am
> inclined to think maybe this isn't a Django 1.10 fault, because the
> migration in Jessie clearly says it depends on a migration that was
> never applied - because it doesn't even exist at this point.
No. This is django making the wrong decision about problems it has
previously supported when trying to include bug fixes for other
problems. It is a regression in django 1.10.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
pgpNiC3J3VJ8h.pgp
Description: OpenPGP digital signature
