"RuntimeError: Error creating new content types."

[Christophe Pettus]

On Django 1.8, I'm encountering this error when attempting to apply migrations on the production system. What's interesting is that it works fine on the dev system, and inspecting the django_migrations table, I don't see any (meaningful) differences between them (error text below).

There was a model added to the "catalog" application which is not being created in django_content_type.

Manually migrating contenttypes individually generates the same error.

--

$ python manage.py migrate
Operations to perform:
Synchronize unmigrated apps: staticfiles, util, treebeard, messages, office
Apply all migrations: info, customers, sessions, admin, contenttypes, auth, sites, catalog, coming_soon, orders
Synchronizing apps without migrations:
Creating tables...
Running deferred SQL...
Installing custom SQL...
Running migrations:
Rendering model states... DONE
Applying auth.0006_require_contenttypes_0002... OK
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/core/management/base.py", line 390, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/core/management/base.py", line 441, in execute
output = self.handle(*args, **options)
File "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 225, in handle
emit_post_migrate_signal(created_models, self.verbosity, self.interactive, connection.alias)
File "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/core/management/sql.py", line 280, in emit_post_migrate_signal
using=db)
File "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 201, in send
response = receiver(signal=self, sender=sender, **named)
File "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py", line 82, in create_permissions
ctype = ContentType.objects.db_manager(using).get_for_model(klass)
File "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/contrib/contenttypes/models.py", line 78, in get_for_model
"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.
--
-- Christophe Pettus
x...@thebuild.com

[Christophe Pettus]

Digging into this a bit more, the specific exception is that it is trying to insert a contenttypes row with a null 'name' value.

The code in question is doing a get_or_create() on the contenttype object. I assume it should be picking up the name from the name @property on the ContentType model, but I don't see that ever actually being called.

> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/84FEBC7D-9A57-47FA-9429-A834A2F03021%40thebuild.com.
> For more options, visit https://groups.google.com/d/optout.

[Tim Graham]

The contenttypes name column was removed in Django 1.8. Could you retrieve the underlying exception before the RuntimeError is raised?

[Christophe Pettus]

Well, django_content_type.name definitely in my database. :) This is a project that was migrated from 1.6.

The underlying exception was a null value complaint about django_content_type.name; it appears as though (on the production database) it thought that the migration to remove had been applied, but in fact had not been.

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/188d28af-be58-4886-9b89-a8aa410e0114%40googlegroups.com.

[Shubham Goyal]

Facing the same problem. Any leads..??

[Max Usachev]

Try to migrate auth application first, and then others:

manage.py migrate auth

manage.py migrate

среда, 29 апреля 2015 г., 14:12:33 UTC+3 пользователь Shubham Goyal написал:

[Devang Mundhra]

I am getting the same error on Django v1.8.2 after migrating from v1.7.7

The underlying error is this-

django.db.utils.IntegrityError: null value in column "name" violates not-null constraint
DETAIL:  Failing row contains (39, null, app_name, model_name).

[Tim Graham]

If anyone running into this problem can figure out why the contrib.contenttypes migration (0002_remove_content_type_name) is being marked as applied but not actually run in the database, that will help determine if this is a bug in Django or a problem elsewhere.

[Devang Mundhra]

In my case this is not a Django bug.
The problem was that since 1.8 contenttypes started to have migrations. But since the table already existed earlier, the migrations needed to be faked.

When faking the migrations, I used python manage.py migrate contenttypes --fake which faked both 0001 and 0002.

The fix was to remove the fake migration for 0002 from django_migrations table and then do the actual migration.

You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/DlRQOdsJL6o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/67e07074-93e6-4e8d-9e0a-afe9d4e6ef22%40googlegroups.com.

[Chris DiLorenzo]

I'm seeing this issue as well. Not sure if it helps but I get it when running my tests.

I chose to raise the error instead and saw this:

django.db.utils.IntegrityError: null value in column "name" violates not-null

constraint
DETAIL:  Failing row contains (1, null, app, listing).

Where app is the django app name and listing is the model name. So that sounds to me like I'm seeing what everyone else is, the migration is just not applied on the database for some reason, but shows as being applied OK.

// Chris

[Devang Mundhra]

Chris-

By any chance, did you fake any of the migrations. That was the problem I had faced- it wasn't a Django problem, it was a problem with my migration.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6186cdbc-9c8c-4a7d-8d94-0b4eb05b9421%40googlegroups.com.

[Chris DiLorenzo]

Hey Devang,

No, we did not fake any migrations =(

[Tomas Henriquez]

I just fixed this issue by entering into my database directly, showed all rows on "django_migrations", I saw that I did migrated before the contenttypes (probably when I did a regression to django 1.4 for some tests). By deleting the rows with contenttypes on it, deleting the contenttypes table and running the migration again I was able to fix the issue.

[Chris DiLorenzo]

While poking around with this again, I noticed that the thing causing the error for me was a datamigration (being applied due to it being run in tests) which is (I believe) why I was seeing the issue when trying to run tests but not otherwise. I was trying to grab a contenttype using ContentType.objects.get_for_model(MODEL). So my current belief is that no ContentType was created for that MODEL before that datamigration was run, thus causing it to fail the creation causing the error. Hope that helps.

[Tobias McNulty]

I just ran into this issue as well when updating an old project to Django 1.8. The only suitable workaround I found was to update first to Django 1.7 and fake the initial migrations for my apps (presumably Django's as well, though it seems to handle that automatically). Only then can you safely update to Django 1.8. Otherwise, there is no way to fake only the initial migrations for the auth and contenttypes apps if you've already upgraded to Django 1.8 (perhaps there should be?).

Tobias

-- 

Tobias McNulty
Chief Executive Officer

tob...@caktusgroup.com

www.caktusgroup.com 

[Allen Romero]

Good tip. First upgrading to Django 1.7 then running the migrations then upgrading to 1.8 also fixed this for me :)

[Tim Graham]

I am not sure if there's a bug in Django or if it's user error that's causing these problems. If I run syncdb on the Django 1.6 with the tutorial, then upgrade directly to 1.8, all seems okay:

$ python manage.py migrate --fake-initial
Operations to perform:
  Apply all migrations: contenttypes, polls, auth, sessions, admin

Running migrations:
  Rendering model states... DONE

  Applying contenttypes.0001_initial... FAKED
  Applying auth.0001_initial... FAKED
  Applying admin.0001_initial... FAKED
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying polls.0001_initial... FAKED
  Applying sessions.0001_initial... FAKED

Are you using --fake instead of --fake-initial? If not, a minimal project to reproduce the crash would be helpful.

[Carl Meyer]

On 07/26/2015 10:46 AM, Tobias McNulty wrote:
> I just ran into this issue as well when updating an old project to
> Django 1.8. The only suitable workaround I found was to update first to
> Django 1.7 and fake the initial migrations for my apps (presumably
> Django's as well, though it seems to handle that automatically). Only
> then can you safely update to Django 1.8. Otherwise, there is no way to
> fake only the initial migrations for the auth and contenttypes apps if
> you've already upgraded to Django 1.8 (perhaps there should be?).

I believe the way to do this is the `--fake-initial` flag to `manage.py
migrate`. It's mentioned in the migrations docs, as well as the 1.8
release notes.

In 1.7, the behavior enabled by `--fake-initial` (automatically fake any
migration where it looks like its tables already exist) was always on,
but we felt that was a bit too implicit and magical. Especially
considering that "tables already exist" is a very rough heuristic for
"is the initial migration already applied", which silently fails to
catch any kind of mismatch at the field/column level. So in 1.8 we
require the use of that heuristic to be explicitly requested.

`--fake-initial` should work equally well for your own apps or Django
contrib apps. Did you try it and it didn't work? Or were you not aware
of it? If the latter, is there someplace it ought to be documented but
isn't?

Carl

[Roger Hunwicks]

On 1.8 `--fake-initial` only works if you have a single initial migration per app. We don't because we have additional migrations to load data and create database triggers, etc.

In 1.9 this will be handled by the `initial = True`  setting on the Migration class.

Until then, we are using:

./manage.py migrate --fake-initial contenttypes

./manage.py migrate --fake

Of course this relies on you being certain that your existing database is exactly the same as it would be if all the migrations were applied to an empty database and there is no sanity-checking.