Django custom User shoots an import issue at runtime when syncing db

Question

I have a custom User model defined in app.models. It is also correctly defined in the AUTH_USER_MODEL setting as app.User. When I run the site, everything works perfectly.

However, when I run ./manage.py syncdb --migrate it breaks with the following traceback:

Traceback (most recent call last):
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/base.py", line 222, in run_from_argv
    self.execute(*args, **options.__dict__)
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/base.py", line 255, in execute
    output = self.handle(*args, **options)
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/base.py", line 386, in handle
    return self.handle_noargs(**options)
  File ".virtualenv/lib/python2.7/site-packages/south/management/commands/syncdb.py", line 103, in handle_noargs
    management.call_command('migrate', **options)
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/__init__.py", line 161, in call_command
    return klass.execute(*args, **defaults)
  File ".virtualenv/lib/python2.7/site-packages/raven/contrib/django/management/__init__.py", line 37, in new_execute
    return original_func(self, *args, **kwargs)
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/base.py", line 255, in execute
    output = self.handle(*args, **options)
  File ".virtualenv/lib/python2.7/site-packages/south/management/commands/migrate.py", line 111, in handle
    ignore_ghosts = ignore_ghosts,
  File ".virtualenv/lib/python2.7/site-packages/south/migration/__init__.py", line 233, in migrate_app
    migrator.load_initial_data(target, db=database)
  File ".virtualenv/lib/python2.7/site-packages/south/migration/migrators.py", line 224, in load_initial_data
    call_command('loaddata', 'initial_data', verbosity=self.verbosity, database=db)
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/__init__.py", line 161, in call_command
    return klass.execute(*args, **defaults)
  File ".virtualenv/lib/python2.7/site-packages/raven/contrib/django/management/__init__.py", line 37, in new_execute
    return original_func(self, *args, **kwargs)
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/base.py", line 254, in execute
    self.validate()
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/base.py", line 285, in validate
    raise CommandError("One or more models did not validate:\n%s" % error_text)
CommandError: One or more models did not validate:
auth.user: Model has been swapped out for 'app.User' which has not been installed or is abstract.

When I run ./manage.py syncdb --migrate app everything runs correctly, so I don't get what's up here. Does anyone have a clue?

EDIT: Order of my installed apps:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.admin',
    'django.contrib.webdesign',
    'django.contrib.staticfiles',
    'djcelery',
    'app',

    'babeldjango',
    'debug_toolbar',
    'template_timings_panel',
    'devserver',
    'django_extensions',
    'djrill',
    'facebook_tag',
    'gunicorn',
    'haystack',
    'markitup',
    'modeltranslation',
    'raven.contrib.django',
    'reversion',
    'rosetta',
    'sorl.thumbnail',
    'south',
    'statictastic',
    'storages',
    'twitter_tag',
    'zebra',
    'djcelery',
    'djmoney_rates'
)

EDIT 2: The issue seems to be arising from the migrations run in third party apps. If I comment out those apps that have migrations, everything goes smoothly. I guess this is also expected since ./manage.py migrate app works fine, but ./manage.py migrate (which runs migrations for all apps) doesn't. And building off of that information and the trace, it seems that my app's models are simply not available when the third party apps' migrations are being run.

Move app up on the list possible. Django cares a metric shitton about the ordering of models. (Within their respective files at least) — Mike McMahon, Nov 14 '13 at 17:31
I've tried moving it to the top of the list (just under `django.contrib.auth`) and I still get the same results. — tzenderman, Nov 14 '13 at 17:58
@tzenderman, your last edit is what exactly happening looking at https://github.com/django/django/blob/master/django/db/models/loading.py `BaseAppCache.get_model()` but it's not clear why it is happening. Do you use virtual env? May be try commenting out 3d party apps one by one and running `migrate`. — twil, Nov 14 '13 at 18:39
Hey @twil, I don't understand your last comment. I did comment out the apps one by one that failed during migrations, but that's not a solution because I need them :) Maybe it helps understand the cause of the issue though? — tzenderman, Nov 14 '13 at 18:53
@tzenderman, do they all (all 3d party apps) throw that exception? If it is only one or two (or even three) of them then it may be possible to figure out the problem — twil, Nov 14 '13 at 21:35
It seems like it's down to djcelery, django-extensions, and reversion, although it only happens when you're using a custom User. — tzenderman, Nov 14 '13 at 23:14

score 2 · Accepted Answer · answered Oct 02 '14 at 10:16

2

Had the same problem, solved it migrating from South 0.8.3 to South 0.8.4

Saw the solution here: http://south.aeracode.org/ticket/1179

answered Oct 02 '14 at 10:16

MiguelSR

166
1
8

While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. – Cyclonecode Oct 02 '14 at 11:02
1

@KristerAndersson, this is not a link only answer. That's not to say that it isn't low quality (I'm not familiar enough with the subject at hand to judge that, but if you are and it is, downvote it). Although the answer is scant on details, it does have more than just a link: it lets us know that we should move from one version of the software to another. It's not much, but it is a valid attempt at an answer. See Your Answer is in Another Castle, when an Answer is not an Answer: http://meta.stackexchange.com/questions/225370/your-answer-is-in-another-castle-when-is-an-answer-not-an-answer – ArtOfWarfare Oct 02 '14 at 12:44

Django custom User shoots an import issue at runtime when syncing db

1 Answers1