initial migration fails just after switching to django-1.7(beta)

[Thomas Capricelli]

I'm currently testing 1.7beta.

I've had the problem for several days. Currently using django 1.7 branch of git as of today.

The code for my application is using django-1.6 but is almost ready for 1.7. The only remaining change is the deletion of admin.autodiscover() in urls.py (can't do that in 1.6).

The db has "never seen" django 1.7 before. I'm starting my test from a copy of the production db (mysql) imported in sqlite using djang 1.6.

I then switch to django 1.7 and does this :

% ./manage.py check
System check identified no issues (0 silenced).

% ./manage.py migrate
Operations to perform:

Synchronize unmigrated apps: main, registration
Apply all migrations: sessions, admin, sites, flatpages, contenttypes, auth

Synchronizing apps without migrations:

Creating tables...
Installing custom SQL...
Installing indexes...

Running migrations:

Applying contenttypes.0001_initial...Traceback (most recent call last):
File "./manage.py", line 7, in <module>

execute_from_command_line(sys.argv)

File "/usr/lib64/python2.7/site-packages/django/core/management/init.py", line 385, in execute_from_command_line

utility.execute()

File "/usr/lib64/python2.7/site-packages/django/core/management/init.py", line 377, in execute

self.fetch_command(subcommand).run_from_argv(self.argv)

File "/usr/lib64/python2.7/site-packages/django/core/management/base.py", line 288, in run_from_argv

self.execute(*args, options.dict)

File "/usr/lib64/python2.7/site-packages/django/core/management/base.py", line 337, in execute

output = self.handle(*args, options)

File "/usr/lib64/python2.7/site-packages/django/core/management/commands/migrate.py", line 148, in handle

executor.migrate(targets, plan, fake=options.get("fake", False))

File "/usr/lib64/python2.7/site-packages/django/db/migrations/executor.py", line 62, in migrate

self.apply_migration(migration, fake=fake)

File "/usr/lib64/python2.7/site-packages/django/db/migrations/executor.py", line 96, in apply_migration

migration.apply(project_state, schema_editor)

File "/usr/lib64/python2.7/site-packages/django/db/migrations/migration.py", line 107, in apply

operation.database_forwards(self.app_label, schema_editor, project_state, new_state)

File "/usr/lib64/python2.7/site-packages/django/db/migrations/operations/models.py", line 36, in database_forwards

schema_editor.create_model(model)

File "/usr/lib64/python2.7/site-packages/django/db/backends/schema.py", line 270, in create_model

self.execute(sql, params)

File "/usr/lib64/python2.7/site-packages/django/db/backends/schema.py", line 98, in execute

cursor.execute(sql, params)

File "/usr/lib64/python2.7/site-packages/django/db/backends/utils.py", line 81, in execute

return super(CursorDebugWrapper, self).execute(sql, params)

File "/usr/lib64/python2.7/site-packages/django/db/backends/utils.py", line 65, in execute

return self.cursor.execute(sql, params)

File "/usr/lib64/python2.7/site-packages/django/db/utils.py", line 94, in exit

six.reraise(dj_exc_type, dj_exc_value, traceback)

File "/usr/lib64/python2.7/site-packages/django/db/backends/utils.py", line 65, in execute

return self.cursor.execute(sql, params)

File "/usr/lib64/python2.7/site-packages/django/db/backends/sqlite3/base.py", line 485, in execute

return Database.Cursor.execute(self, query, params)

django.db.utils.OperationalError: table "django_content_type" already exists

I can turn around this using --fake.

I'm not totally sure it's exactly the same problem, but this second one does look very close :

The "main" application you see upthere is so-called 'unmigrated'. Following the doc, i migrate using "makemigrations", and then migrate again.

I got the same django.db.utils.OperationalError table already exists on the first model created by this migration.

My reference is :
​https://docs.djangoproject.com/en/1.7/topics/migrations/#adding-migrations-to-apps

that says :
"This will make a new initial migration for your app. Now, when you run migrate, Django will detect that you have an initial migration and that the tables it wants to create already exist, and will mark the migration as already applied."

[Chris Beaven]

Error is due to test_soft_apply failing if any non-CreateModel migrations exist in the initial migration. This is the case for contenttypes (and since that's so simple, surely many other initial migrations too).

[Thomas Capricelli]

i confirm that it is also the case in the migration created by makemigration. For some really weird reasons i dont understand, instead of creating normal "ForeignKey" it first creates the model without it, then does

migrations.AddField()

This model is called "Candidat", and is defined last in my models.py (because it has ForeignKey's on model defined before, i know i could use strings but i dont here). In the migration file, the order is

• create "Candidat"
• create another one
• migrations.AddField to add a key in "Candidat" toward this second model.

"Candidat" also has a ForeignKey to "User" but this one is defined normally in the migration file.

That looks like :

---

operations = [

migrations.CreateModel(

name='Candidat',
fields=[

...
('user', models.ForeignKey(to=settings.AUTH_USER_MODEL, to_field='id', unique=True)),
...

]

),
migrations.CreateModel(

name='Other',
fields=..

),
migrations.AddField(

model_name='candidat',
name='other',
field=models.ForeignKey(to='main.Other', to_field='id'),
preserve_default=True,

),

---

[Chris Beaven <smileychris@…>]

In 21c496ea52b8bdf0d97507c00a87286425dac087:

Fixed #22881 -- Better soft_applied migration detection

[Chris Beaven <smileychris@…>]

In 29582ad4a3ef5888ef86a45167ed8e7414c1347e:

[1.7.x] Fixed #22881 -- Better soft_applied migration detection

[anonymous]

Did this cause ​http://ci.djangoproject.com/job/Django/4693/database=mysql,python=python3.2/testReport/junit/migrations.test_commands/MigrateTests/test_sqlmigrate/ ? If yes, please fix ASAP or revert.

[Thomas Capricelli]

I tried with an updated django and it fixes both my problems indeed..
Thanks !

(I'm no authoritative, but the ci error doesn't seem related)

[Tim Graham <timograham@…>]

In 908160f6926506dc64244e9d5a4507bc67ea0a81:

Fixed test failures introduced by refs #22881.

[Tim Graham <timograham@…>]

In 21c959138401bd9f57fd789409c80add01c4b075:

[1.7.x] Fixed test failures introduced by refs #22881.

Backport of 908160f692 from master