django south - stale user model when using AbstractUser - django

Question

I am trying to get to grips with django and south, and I seem to have run into stale contenttype problem - and I am not able to find a fix for it on SO or google.
So, to start with I have a simple project on django==1.6 with the following on installed apps:
INSTALLED_APPS = (
'django.contrib.auth',
'django_browserid', # Load after auth
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
'django.contrib.sitemaps',
# Uncomment the next line to enable the admin:
'django.contrib.admin',
# Uncomment the next line to enable admin documentation:
# 'django.contrib.admindocs',
'south',
)
AUTH_USER_MODEL = 'auth.User'
and I run a syncdb on this and do not create a superuser at this stage.
Now, I create a new app loginapp and create an AbstractUser as follows:
#loginapp/models.py
class MyUser(AbstractUser):
is_admin_enabled = models.BooleanField(default=True) # new field
and change the following on my settings.py:
AUTH_USER_MODEL = "loginapp.MyUser"
now, on the login app, I run (I add loginapp to my INSTALLED_APPS dict):
python manage.py schemamigration loginapp --initial && python manage.py migrate loginapp
..all is fine so far - I can see that south has created the new User model on my db.
Now, I go back and do a syncdb on my project and I get:
The following content types are stale and need to be deleted:
auth | user
Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.
.. I am guessing django realizes that the user model has changed and the default model is now obsolete. I tried using "yes" here and I see the DB tables are still there - presumably because syncdb does not delete database tables.
How do I avoid the above problem in the first place? I just need the user model as defined in my loginapp and not the default django user model on my DB - using south.
Would really appreciate any clues/direction to solve this issue.

Answer 1

I ran into a similar problem using Django 1.7 migrations to migrate auth.models.User to myapp.User (that inherits from AbstractUser), and didn't want to wipe my existing production admin logs table entries that have to do with User, so I insisted on getting this absolutely right.
Assuming myappp.models is:
from django.db import models
from django.contrib.auth.models import AbstractUser
class User(AbstractUser):
class Meta:
db_table = 'auth_user'
Here is what I came up with:
from django.db import models, migrations
import django.utils.timezone
import django.core.validators
MYAPP = 'myapp'
def migrate_func(old, new, apps, schema_editor):
ContentType = apps.get_model("contenttypes", "ContentType")
db_alias = schema_editor.connection.alias
ct = ContentType.objects.using(db_alias).get(app_label=old, model='user')
ct.app_label = new
ct.save()
def forwards_func(apps, schema_editor):
migrate_func('auth', MYAPP, apps, schema_editor)
def backwards_func(apps, schema_editor):
migrate_func(MYAPP, 'auth', apps, schema_editor)
class Migration(migrations.Migration):
dependencies = [
...
]
database_operations = [
migrations.RunPython(forwards_func, backwards_func)
]
state_operations = [
migrations.CreateModel(
name='User',
fields=[
('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
...
],
options={
'db_table': 'auth_user',
},
bases=(models.Model,),
),
]
operations = [
migrations.SeparateDatabaseAndState(
state_operations=state_operations),
migrations.SeparateDatabaseAndState(
database_operations=database_operations)
]