migrations to custom user model - complex project

[Frank Bieniek]

Hi All,
a do have to upgrade an existing
django project, it is an openid provider with around 10k users.
In order to update to django 1.6 I do need to get rid of
the good old AUTH_PROFILE_MODULE and need to switch
to CustomUserModel, and I do not want to break existing mysql constraints.

Django==1.5.5
South==0.8.4
python-openid
django-tastypie==0.10.0
django-guardian==1.1.1
django_openid_provider
django-userena==1.2.4
...
But I do not want to touch only a minimal set of files possible
and do not want to do a dumpdata load data mess.

There must be an elegant solution, someone else has already done

Any hints are welcome - I googled already, but have not found a solution
that does not break groups or other fks...


Thanks
Frank

[Arnold Krille]

Hi,

On Fri, 24 Jan 2014 15:10:44 +0100 Frank Bieniek
<frank....@produktlaunch.de> wrote:
> a do have to upgrade an existing
> django project, it is an openid provider with around 10k users.
> In order to update to django 1.6 I do need to get rid of
> the good old AUTH_PROFILE_MODULE and need to switch
> to CustomUserModel, and I do not want to break existing mysql
> constraints.

> But I do not want to touch only a minimal set of files possible
> and do not want to do a dumpdata load data mess.
> There must be an elegant solution, someone else has already done
> Any hints are welcome - I googled already, but have not found a
> solution that does not break groups or other fks...

We did something similar, we switched from djangos own user model + our
profile to just using our profile extended by email and password (no
username anymore and no openid (yet)).

What you need to do depends on whether you can keep the ID's the same
or not. We couldn't so we had to do the following:
- In all models that had a foreignkey on the django-user, we added
another foreignkey on the new user (with default=null).
- Then we added a data-migration to fill the columns for the new
user-model with the ids.
- In the next migration we deactivated all triggers for the
transaction, removed the constraints for the old django-user
reference and added constraints for the new user-model.
- Then the references to the old django-user can be removed. And once
you defined your user model for django.auth, you have to write your
own migration to drop the user-model tables from django.auth
(because south doesn't see that table and model anymore).
- We also renamed the references to the new user-model to be same as
the references to the old user-model before all these migrations. So
most code didn't need changing.
- Of course you also have to adopt your python code for the
specialties of the new user model...

If you can keep the IDs the same as before, you probably don't need to
add a second column for the new model reference. You can 'just' remove
the constraints from each foreignkey pointing to the old user-model and
replace it with a constraint pointing to the new user-model. Of course,
before you do that you need a migration creating your new user-model
and a data-migration to copy the user-data (most importantly the IDs!)
to the new tables.

Maybe that helps,

- Arnold

[Frank Bieniek]

Thanks Arnold, for the details.

Am 25.01.14 21:22, schrieb Arnold Krille: