Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#22411 closed Bug (fixed)

Migrations attempt to create content types without first running contenttypes sync/migrations

Reported by: melinath Owned by: nobody
Component: Migrations Version: 1.7-beta-1
Severity: Normal Keywords:
Cc: melinath, Tim Graham Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


If I am (for some reason) just migrating a single app on a fresh database, Django will try to create contenttypes for the app's models. But since it hasn't actually synced the contenttypes app yet, the creation fails. While this doesn't seem to affect the actual state of the migrations, it is startling and confusing, and seems unnecessary. I'm not sure which would be better:

  1. Always migrating contenttypes before trying to create.
  2. Only trying to create if contenttypes has already been migrated.
$ ./ migrate <myapp>
Operations to perform:
  Apply all migrations: <myapp>
Running migrations:
  <migrations - all successful>
Traceback (most recent call last):
  File "./", line 10, in <module>
  File ".../django/django/core/management/", line 427, in execute_from_command_line
  File ".../django/django/core/management/", line 419, in execute
  File ".../django/django/core/management/", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File ".../django/django/core/management/", line 337, in execute
    output = self.handle(*args, **options)
  File ".../django/django/core/management/commands/", line 149, in handle
    emit_post_migrate_signal(created_models, self.verbosity, self.interactive, connection.alias)
  File ".../django/django/core/management/", line 246, in emit_post_migrate_signal
  File ".../django/django/dispatch/", line 198, in send
    response = receiver(signal=self, sender=sender, **named)
  File ".../django/django/contrib/auth/management/", line 85, in create_permissions
    ctype = ContentType.objects.db_manager(using).get_for_model(klass)
  File ".../django/django/contrib/contenttypes/", line 49, in get_for_model
    defaults={'name': smart_text(opts.verbose_name_raw)},
  File ".../django/django/db/models/", line 92, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File ".../django/django/db/models/", line 417, in get_or_create
    return self.get(**lookup), False
  File ".../django/django/db/models/", line 346, in get
    num = len(clone)
  File ".../django/django/db/models/", line 122, in __len__
  File ".../django/django/db/models/", line 961, in _fetch_all
    self._result_cache = list(self.iterator())
  File ".../django/django/db/models/", line 265, in iterator
    for row in compiler.results_iter():
  File ".../django/django/db/models/sql/", line 694, in results_iter
    for rows in self.execute_sql(MULTI):
  File ".../django/django/db/models/sql/", line 780, in execute_sql
    cursor.execute(sql, params)
  File ".../django/django/db/backends/", line 77, in execute
    return super(CursorDebugWrapper, self).execute(sql, params)
  File ".../django/django/db/backends/", line 61, in execute
    return self.cursor.execute(sql, params)
  File ".../django/django/db/", line 94, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File ".../django/django/db/backends/", line 61, in execute
    return self.cursor.execute(sql, params)
  File ".../django/django/db/backends/sqlite3/", line 479, in execute
    return Database.Cursor.execute(self, query, params)
django.db.utils.OperationalError: no such table: django_content_type

Change History (8)

comment:1 Changed 3 years ago by melinath

I would lean towards number 2 (Only trying to create if contenttypes has already been migrated) because explicit is better than implicit.

comment:2 Changed 3 years ago by Tim Graham

Triage Stage: UnreviewedAccepted

comment:3 Changed 3 years ago by melinath

One option would be to always have a dependency on contenttypes in initial migrations:

dependencies = [
    ('contenttypes', '__first__'),

Untested, but I think it would work.

comment:4 Changed 3 years ago by Tim Graham

Cc: Tim Graham added

I don't think adding a dependency on contenttypes would be wise since the app should be optional and if we added that then if django.contrib.contenttypes isn't in INSTALLED_APPS, you'd get an error when migrating: ValueError: Dependency on unknown app contenttypes. This raises a more general issue that unlike the post_syncdb signal, when post_migrate is fired there's no guarantee that the tables for all other apps will exist. I'm not sure if there's an existing method to check whether or not a model's table has been created.

comment:5 Changed 3 years ago by melinath

This *should* be resolved by #22485, but I can't test myself due to the introduction of #22563.

comment:6 Changed 2 years ago by Tim Graham

It still appears an issue, but I wonder if we should just document this or throw a more helpful error message?

comment:7 Changed 2 years ago by Andrew Godwin <andrew@…>

Resolution: fixed
Status: newclosed

In 7a259008a76c5bcd6c1e5ba3a45d17a6184c4242:

Fixed #22411: Throw a more helpful error if contenttypes doesn't exist.

comment:8 Changed 2 years ago by Andrew Godwin <andrew@…>

In c5578ba9fa052a814c27fe0069f98ed994751634:

[1.7.x] Fixed #22411: Throw a more helpful error if contenttypes doesn't exist.



Note: See TracTickets for help on using tickets.
Back to Top