Hi, On Fri, 24 Jan 2014 15:10:44 +0100 Frank Bieniek <frank.bien...@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
signature.asc
Description: PGP signature
