Document how to avoid ""RuntimeError: Error creating new content types." when upgrading to 1.8 (skipping 1.7)

[Sachin philip Mathew]

• Project Build on django 1.4.10
• Database - postgresql (which got large amount data)

Steps to Reproduce issues

1. Upgraded to django 1.8.*
2. Create a new table
3. executing makemigrations works fine
4. when we migrate, migrations works and gives ok response then followed by

"Error creating new content types. Please make sure contenttypes "
RuntimeError: Error creating new content types. Please make sure contenttypes is migrated before trying to migrate apps individually.

5. Then try to access this table from admin it gives responce

Error creating new content types. Please make sure contenttypes is migrated before trying to migrate apps individually.

6. tried migrate contenttype - nothing changes

7. Downgraded to django 1.7 , and executing migration for contenttype works and issue will be resolved

Each and everytime we need to follow this same process not just once, each and everytime when we create a new table not column

[Sachin philip Mathew]

Migration error responce

[Tim Graham]

Please see if ​https://groups.google.com/d/topic/django-users/DlRQOdsJL6o/discussion helps. Are you faking the contenttypes migrations which causes both 0001 and 0002 to be faked? Maybe we could add a tip about this in the 1.8 release notes since it seems to be a common issue. migrate --fake-initial might resolve that.

[Sachin philip Mathew]

No i am not faking it

This is what really happens in 1.8

i try migrate --fake-initial - it didnt work

Response:
It says Your models have changes that are not yet reflected in a migration, and so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.

with the same bunch of contenttype errors

Only Solution i really found was Downgrading to 1.7.* and migrating contenttypes individually

migrate contenttypes

Response will be the same
It says Your models have changes that are not yet reflected in a migration, and so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.

but there wont be any errors and issue will be solves temporarily

Note: now we can goback to 1.8 and go on with the developments . Migrations wont have any issue in 1.8 untill we add a new table(i didnt find any issues with columns ). If we add new table we should again do the same procedures .

[Tim Graham]

I'm not sure what's going on, and I think we need a sample project to reproduce the issue.

[Tim Graham]

Steps to reproduce:
1) Have a pre-1.7 project.
2) Upgrade to Django 1.8 (skipping 1.7) and run manage.py migrate --fake.
3) Now, 0002_remove_content_type_name.py will get fake-applied and the name column in the django_content_type table won't be dropped.

We should recommend using migrate --fake-initial in the 1.8 release notes for this case.

[Tim Graham]

​PR

[Tim Graham <timograham@…>]

In 81b55fb:

Fixed #25100 -- Documented an upgrade caveat for contenttypes migration.

[Tim Graham <timograham@…>]

In 8b1c386:

[1.9.x] Fixed #25100 -- Documented an upgrade caveat for contenttypes migration.

Backport of 81b55fb90078788bfdc064550f2ff9da2c79d3b6 from master

[Tim Graham <timograham@…>]

In 052bd3f:

[1.8.x] Fixed #25100 -- Documented an upgrade caveat for contenttypes migration.

Backport of 81b55fb90078788bfdc064550f2ff9da2c79d3b6 from master