UsersProfile breaks syncdb

[btbonval]

I was trying to syncdb --migrate a new database for testing the restore functionality of #89, but I got this error from users_userprofile that looks like the migrations are trying (and failing) to add data into the database?

vagrant@vagrant-ubuntu-precise-32:~/karmaworld$ fab -H 127.0.0.1 syncdb
[127.0.0.1] Executing task 'syncdb'
[127.0.0.1] run: find -L /var/www/karmaworld -path '*/bin/activate' | grep -v '/local/'
[127.0.0.1] out: /var/www/karmaworld/venv/bin/activate
[127.0.0.1] out: 

[127.0.0.1] run: /var/www/karmaworld/manage.py syncdb --migrate
[127.0.0.1] out: Syncing...
[127.0.0.1] out: Creating tables ...
[127.0.0.1] out: Creating table auth_permission
[127.0.0.1] out: Creating table auth_group_permissions
[127.0.0.1] out: Creating table auth_group
[127.0.0.1] out: Creating table auth_user_groups
[127.0.0.1] out: Creating table auth_user_user_permissions
[127.0.0.1] out: Creating table auth_user
[127.0.0.1] out: Creating table django_content_type
[127.0.0.1] out: Creating table django_session
[127.0.0.1] out: Creating table django_site
[127.0.0.1] out: Creating table django_admin_log
[127.0.0.1] out: Creating table south_migrationhistory
[127.0.0.1] out: Creating table taggit_tag
[127.0.0.1] out: Creating table taggit_taggeditem
[127.0.0.1] out: Creating table account_emailaddress
[127.0.0.1] out: Creating table account_emailconfirmation
[127.0.0.1] out: 
[127.0.0.1] out: You just installed Django's auth system, which means you don't have any superusers defined.
[127.0.0.1] out: Would you like to create one now? (yes/no): yes
[127.0.0.1] out: Username (leave blank to use 'vagrant'): vagrant
[127.0.0.1] out: Email address: vagrant@vagrant.vg
[127.0.0.1] out: Password: 
[127.0.0.1] out: Password (again): 
[127.0.0.1] out: DatabaseError: relation "users_userprofile" does not exist
[127.0.0.1] out: LINE 1: INSERT INTO "users_userprofile" ("user_id", "school_id", "ka...
[127.0.0.1] out:                     ^
[127.0.0.1] out: 

Fatal error: run() received nonzero return code 1 while executing!

Requested: /var/www/karmaworld/manage.py syncdb --migrate
Executed: /bin/bash -l -c "source /var/www/karmaworld/venv/bin/activate && /var/www/karmaworld/manage.py syncdb --migrate"

[btbonval]

Ah, it might be due to Django 1.5. A SO answer pointed me to a blog (from 2008) which said Django 1.5 effectively replaced the need for the usual UserProfile scheme. http://stackoverflow.com/questions/5843580/auth-profile-module-in-django http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/ https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#auth-custom-user

This indicates the following line either does nothing in 1.5 or possibly causes problems: https://github.com/FinalsClub/karmaworld/blob/master/karmaworld/settings/common.py#L259

It looks like profiles should be handled via CustomUser: https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#django.contrib.auth.models.CustomUser

These are guesses as to why Django decided to perform an INSERT during a migration.

[btbonval]

derpderpderp how did I miss it until now?

The error from INSERT came directly after trying to create the Admin user.

So the semi-automagic superuser creation is borking on UserProfile because UserProfile doesn't exist when the user creation is performed. Not sure what to do about this or why the semi-automagic superuser creation knows to touch UserProfile. Possibly the AUTH_PROFILE_MODULE line?

[charlesconnell]

There's a method attached to the User.post_save signal that creates a UserProfile associated with that user. It's failing because the table doesn't exist yet.

Bryan Bonvallet notifications@github.com wrote:

Ah, it might be due to Django 1.5. A SO answer pointed me to a blog (from 2008) which said Django 1.5 effectively replaced the need for the usual UserProfile scheme. http://stackoverflow.com/questions/5843580/auth-profile-module-in-django http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/ https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#auth-custom-user

This indicates the following line either does nothing in 1.5 or possibly causes problems: https://github.com/FinalsClub/karmaworld/blob/master/karmaworld/settings/common.py#L259

It looks like profiles should be handled via CustomUser: https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#django.contrib.auth.models.CustomUser

These are guesses as to why Django decided to perform an INSERT during a migration.

---

Reply to this email directly or view it on GitHub: https://github.com/FinalsClub/karmaworld/issues/270#issuecomment-32136074

• Charles

[btbonval]

Less automatic than I thought. Hrm, I guess we'll have to update the docs about how to add a superuser after the migrations have run, since it looks like you can't make a superuser upon first deploy.

Unless there's someway to change when that user creation dialogue pops up... which would be super nice.

[btbonval]

"With these settings in place, running the command manage.py syncdb creates the necessary database tables for auth related models, creates permissions for any models defined in your installed apps, and prompts you to create a superuser account the first time you run it." https://docs.djangoproject.com/en/1.5/topics/auth/

Seems like order of operations is not as described in Django docs. Can't find how to change that prompt. Found "Migrating to a Custom User Model in Django" while searching for "django auth system superuser prompt migrate", which again suggests user profile data should be handled by way of a custom user model. :( http://www.caktusgroup.com/blog/2013/08/07/migrating-custom-user-model-django/

[btbonval]

Weird that Django can't figure this out and I can't find other people having the same issue.

I suppose the laziest thing to do in this case is to update the docs following this workaround:

1. python manage.py syncdb --migrate --noinput
2. python manage.py createsuperuser

https://docs.djangoproject.com/en/1.5/ref/django-admin/#django-admin-syncdb https://docs.djangoproject.com/en/1.5/ref/django-admin/#createsuperuser

[btbonval]

That workaround was successful. Taking ticket ownership.

Update VM startup so that syncdb runs with noinput and might as well script the VM superuser creation if possible.

Update the docs to show these two steps must be taken, as syncdb without --noinput breaks things when first creating the database.

[AndrewMagliozzi]

Is this fixed now?

On Jan 12, 2014, at 8:17 PM, Bryan Bonvallet notifications@github.com wrote:

That workaround was successful. Taking ticket ownership.

Update VM startup so that syncdb runs with noinput and might as well script the VM superuser creation if possible.

Update the docs to show these two steps must be taken, as syncdb without --noinput breaks things.

— Reply to this email directly or view it on GitHub.

[btbonval]

No, I still have to do those two things in my previous comment. They're fairly low priority.

On Tue, Jan 14, 2014 at 12:38 PM, Andrew Magliozzi <notifications@github.com

wrote:

Is this fixed now?

On Jan 12, 2014, at 8:17 PM, Bryan Bonvallet notifications@github.com wrote:

That workaround was successful. Taking ticket ownership.

Update VM startup so that syncdb runs with noinput and might as well script the VM superuser creation if possible.

Update the docs to show these two steps must be taken, as syncdb without --noinput breaks things.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/FinalsClub/karmaworld/issues/270#issuecomment-32287582 .

[charlesconnell]

I can make a programmatic change to avoid this problem.

[sethwoodworth]

You can merely extend the User model now (post 1.5), a separate UserProfile model isn't required. It was always a silly hack that django required.

On Tue, Jan 14, 2014 at 3:35 PM, Charles Connell notifications@github.comwrote:

I can make a programmatic change to avoid this problem.

— Reply to this email directly or view it on GitHubhttps://github.com/FinalsClub/karmaworld/issues/270#issuecomment-32304639 .

[btbonval]

@sethwoodworth You're right! I've mentioned this once or twice. Unfortunately our upgrade to 1.5.5 is sitting in a branch with a few possibly destructive changes. After that is merged into master, it might be best to go with the Django 1.5 way of doing things, rather than implementing a UserProfile.

[btbonval]

@charlesconnell I was putting the Django 1.5.5 merge on hold because it means you're going to have to redo your dev environment. By email everyone said they are for it, but I want to make sure you're largely done with the features you wanted to add for the week before I merge it.

[charlesconnell]

Go ahead and merge -- I've already got the 1.5 branch running locally.

[btbonval]

Cool. The longer it is put off, the more merge conflicts there will be :(

e.g. migration index number collisions (the dumbest idea since giving small, hard candies to babies).

[btbonval]

since this is still a problem for creating a VM right now, in the django155 branch I added the workaround so that no superuser is created. I have not updated the docs.

[charlesconnell]

I want to keep UserProfile as a separate model than User. I think that it makes sense to have it that way, since they are sufficiently different concepts. I was able to fix this ticket with a small code change.

[btbonval]

Oh I already implemented a workaround. I was leaving the ticket open to document that workaround in the README.

On Wed, Jan 15, 2014 at 4:11 PM, Charles Connell notifications@github.comwrote:

Closed #270 https://github.com/FinalsClub/karmaworld/issues/270.

— Reply to this email directly or view it on GitHubhttps://github.com/FinalsClub/karmaworld/issues/270 .

[btbonval]

Reading your code, I guess the workaround is not necessary. Thanks!