Postgres Table not updating correctly on save with autocommit on

[anonymous]

In a model for my database I am trying to define an Accounts table with the id of a default Django User.

class Accounts(models.Model):
    user = models.OneToOneField(User)

When I have it set up like this and try to add a user in the adduser view:

def adduser(request):
    username = request.POST['username']
    password = request.POST['password']
    u = User.objects.create_user(username, request.POST['email'], password) 
    u.save()
    a = Accounts(user=u)
    p = Passwords(user=u)
    a.save()
    p.save()
    user = authenticate(username=username, password=password)
    if user is not None and user.is_active:
        auth.login(request, user)
        return HttpResponseRedirect("/%s/" %u.id)
    else:
        return HttpResponseRedirect("/account/invalid/")

There is an integrity error:

IntegrityError at /adduser
insert or update on table "XXXX_accounts" violates foreign key constraint   "user_id_refs_id_468fbcec324e93d2"
DETAIL:  Key (user_id)=(10) is not present in table "XXXX_user".

adducer should be saving the user before creating the Accounts class to corresponds, so it shouldn't have an issue with the id being generated automatically by Django, but apparently Postgres has an issue with ForeignKeys.

[Karen Tracey]

Fixed formatting. Please use WikiFormatting and preview before posting.

[Karen Tracey]

Why have you put XXXX in place of some key text in the IntegrityError message? Since you have put the XXXXs in place of what ought to be a Django-provided application table name (specifically, auth_user) I'm suspicious that what has happened here is you are using django.auth.models.User in some places and some other User model in other places. If your User created by adduser is a django.contrib.auth user yet your Account model has a OneToOne field pointing to an entirely different User model that would explain the behavior you are reporting.

[anonymous]

Replying to kmtracey:

Why have you put XXXX in place of some key text in the IntegrityError message? Since you have put the XXXXs in place of what ought to be a Django-provided application table name (specifically, auth_user) I'm suspicious that what has happened here is you are using django.auth.models.User in some places and some other User model in other places. If your User created by adduser is a django.contrib.auth user yet your Account model has a OneToOne field pointing to an entirely different User model that would explain the behavior you are reporting.

Sorry the XXXX are just the name of my Django App. So it should be My_App_accounts violates.... and Key is not present in My_App_users. I am now using the django supplied default user model (importing "from django.contrib.auth.models import User" and that is what is being given to Accounts). In my models I shouldn't have to declare the Django user class should I?

[Karen Tracey]

You say you are NOW using the Django User model. Based on your error message, specifically My_App_users being identified in the integrity error, not auth_users, it sounds like you originally built your models using your own User model? Your database table for Account appears to still be defined in a way where the DB is expecting your Account rows to reference objects in My_App_usres, not auth_users. Note Django itself (syncdb command) does not do any database schema migration, it simply creates tables for models it finds that do not yet have tables in the database. If you are making changes to the models in your Python code, you need to either manually update the database shema to match what you have done on the Python side, or use some tool like South to help with automatically migrating the database schema to match changes you have made to the Python code.

[anonymous]

Replying to kmtracey:

You say you are NOW using the Django User model. Based on your error message, specifically My_App_users being identified in the integrity error, not auth_users, it sounds like you originally built your models using your own User model? Your database table for Account appears to still be defined in a way where the DB is expecting your Account rows to reference objects in My_App_usres, not auth_users. Note Django itself (syncdb command) does not do any database schema migration, it simply creates tables for models it finds that do not yet have tables in the database. If you are making changes to the models in your Python code, you need to either manually update the database shema to match what you have done on the Python side, or use some tool like South to help with automatically migrating the database schema to match changes you have made to the Python code.

Yep I've done schemamigrations using south and then issued migrate but to no effect. Luckily, as I'm just beginning, I have the option of wiping the DB. Would this fix things, allowing it to be rebuilt with only Accounts, Passwords, and the Django user class?

[anonymous]

Replying to kmtracey:

You say you are NOW using the Django User model. Based on your error message, specifically My_App_users being identified in the integrity error, not auth_users, it sounds like you originally built your models using your own User model? Your database table for Account appears to still be defined in a way where the DB is expecting your Account rows to reference objects in My_App_usres, not auth_users. Note Django itself (syncdb command) does not do any database schema migration, it simply creates tables for models it finds that do not yet have tables in the database. If you are making changes to the models in your Python code, you need to either manually update the database shema to match what you have done on the Python side, or use some tool like South to help with automatically migrating the database schema to match changes you have made to the Python code.

Sorry I was looking up how to reset Postgres tables and ran this command 'python Django_App/manage.py sqlsequencereset My_App '. It outputs the following:

BEGIN;
SELECT setval(pg_get_serial_sequence('"My_App_accounts"','id'), coalesce(max("id"), 1), max("id") IS NOT null) FROM "My_App_accounts";
SELECT setval(pg_get_serial_sequence('"My_App_passwords"','id'), coalesce(max("id"), 1), max("id") IS NOT null) FROM "My_App_passwords";
COMMIT;

The user table didn't even show up, but I know it must be there (or something is) because the auto increment on the user_id primary key is working correctly. Does this mean anything to you?