South doesn't use db_table for foreign key constraints

[Anton Agestam]

I'm having issues with third-party packages in Django that has relations with the user model. I've swapped out the user model to a legacy table `users`. After running migrations and syncdb I couldn't save objects in the third-party packages' models because of a foreign key error:

```

(1452, 'Cannot add or update a child row: a foreign key constraint fails (`mcr`.`oauth2_client`, CONSTRAINT `user_id_refs_id_caad7e47` FOREIGN KEY (`user_id`) REFERENCES `user_user` (`id`))')

```

I checked the foreign keys relating to the user model and saw that instead of pointing to `users` the ones in the third-party packages are relating to `user_user` (which would be the default name of the table if wouldn't have specified `db_name = 'users'`).

So I dug further and found this in django-oauth2-provider's (and equivalent in django-tastypie's) South migrations:

```python

    db.create_table('oauth2_client', (

        ('id', self.gf('django.db.models.fields.AutoField')(primary_key=True)),

        ('user', self.gf('django.db.models.fields.related.ForeignKey')(to=orm[user_model_label])),

        ('url', self.gf('django.db.models.fields.URLField')(max_length=200)),

        ('redirect_uri', self.gf('django.db.models.fields.URLField')(max_length=200)),

        ('client_id', self.gf('django.db.models.fields.CharField')(default='37b581bdc702c732aa65', max_length=255)),

        ('client_secret', self.gf('django.db.models.fields.CharField')(default='5cf90561f7566aa81457f8a32187dcb8147c7b73', max_length=255)),

        ('client_type', self.gf('django.db.models.fields.IntegerField')()),

    ))

    db.send_create_signal('oauth2', ['Client'])

```

`user_model_label` is set from `django.conf.settings.AUTH_USER_MODEL`, so should be the correct label (printed it and it's the correct string).

The tables are created correctly but it seems like the foreign keys are messed up somewhere along the way, my initial feeling is that South incorrectly assumes the default name for the table when creating foreign keys.

[Andrew Godwin]

South doesn't support swapped-out user models very well - the migrations there have been manually tweaked to try and support it, but that support only goes so far, and it won't do models and options on the swapped model correctly.

The only real workaround you have is to manually edit those third-party migrations to import the model directly from its file and use that. You won't be able to ever change anything substantial about the user model, but it will at least work. Django 1.7 migrations have much better swappable support.

Andrew

--
You received this message because you are subscribed to the Google Groups "South Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to south-users...@googlegroups.com.
To post to this group, send email to south...@googlegroups.com.
Visit this group at http://groups.google.com/group/south-users.
For more options, visit https://groups.google.com/d/optout.

[Shai Berger]

Hi,

On Monday 02 June 2014 06:37:26 Andrew Godwin wrote:
>
> The only real workaround you have is to manually edit those third-party
> migrations to import the model directly from its file and use that. You
> won't be able to ever change anything substantial about the user model, but
> it will at least work. Django 1.7 migrations have much better swappable
> support.
>

I think there's a better way -- make a migration (anywhere) freezing your user
model; take the frozen model (the entry for the model in the "models" dicts at
the bottom of the migration file), and copy that into the (models dict in the)
migrations in the third-party apps. This should get the 3rd-party-app
migrations to behave, without forcing a freeze on the user model.

HTH,
Shai.

[Anton Agestam]

Cool, I started using the 1.7 beta for this project bumped into a bit too many problems so I downgraded to 1.6 and South. Actually the only thing South didn't get right was the foreign key constraints so I created a new migration in the user app and removed the old indexes and created new ones.

Shai, I'd rather not change the migrations in the third-party apps as I'd have to create forks or vendor them to do that.