5 ms·

I'm looking forward to the swappable User model feature. Has anyone seen or heard of a site that has looked at migrating from a profile approach to a full in sw

I'm looking forward to the swappable User model feature. Has anyone seen or heard of a site that has looked at migrating from a profile approach to a full in swapped User model? What does that migration look like and how painful was it?

superxor 14y ago
God, I was so fed up with django.contrib.auth.models.User, not being able to ignore Username was probably the most insane part, I always felt email was a better choice than Username. I along with a bunch of people I know are looking forward to swappable User model, far saner than the round-about approaches I was using.
- kennu 14y ago
  Very much agree with this. Websites rarely require users to choose a unique username nowadays (email is enough) and it's been a pain hacking Django to work like that, since many email addresses won't fit in the username field. In fact I always hate it when application frameworks make arbitrary decisions at the schema level on how long usernames, real names, emails, street addresses, etc. can be. I always use varchar(254) myself. (Unless using a schemaless db like Mongo where this is not even an issue.)
- Nagyman 14y ago
  It's not terribly straight forward to do this, depending on which apps you may use. E.g. django-registration or even django.contrib.admin. Username is hard coded in many places. It will get there, but apps have some work to do.
  - kmfrk 14y ago
    I think you can just override the default clean_username() in RegistrationForm: https://bitbucket.org/ubernostrum/django-registration/src/27bccd108cdef30dc0a91ed1968be17bb1e60da4/registration/forms.py?at=default#cl-45 https://bitbucket.org/ubernostrum/django-registration/src/27... Looks like that's the only place that enforces duplicate usernames.
StavrosK 14y ago
I should write it up as a blog post. Basically: 1) Create the new User model, and create a schema migration for it. 2) Create a data migration to copy every piece of data you have in your users and profiles over to the new User model. 3) Add ForeignKeys to all your models that reference either the old User model or the Profile. 4) Add a data migration to copy every reference to the old User/Profile from every other model to the new FKs, to point to the corresponding NewUser model. 5) Remove the old FKs with a schema migration. 6) Rename all the new FKs to the old names, create a schema migration, go into it and turn all the delete/creates into column updates. 7) Revert your code to your last commit because you noticed you screwed something up and you can't reverse it now. 8) Done.

superxor 14y ago

God, I was so fed up with django.contrib.auth.models.User, not being able to ignore Username was probably the most insane part, I always felt email was a better choice than Username. I along with a bunch of people I know are looking forward to swappable User model, far saner than the round-about approaches I was using.

kennu 14y ago
Very much agree with this. Websites rarely require users to choose a unique username nowadays (email is enough) and it's been a pain hacking Django to work like that, since many email addresses won't fit in the username field. In fact I always hate it when application frameworks make arbitrary decisions at the schema level on how long usernames, real names, emails, street addresses, etc. can be. I always use varchar(254) myself. (Unless using a schemaless db like Mongo where this is not even an issue.)
Nagyman 14y ago
It's not terribly straight forward to do this, depending on which apps you may use. E.g. django-registration or even django.contrib.admin. Username is hard coded in many places. It will get there, but apps have some work to do.
- kmfrk 14y ago
  I think you can just override the default clean_username() in RegistrationForm: https://bitbucket.org/ubernostrum/django-registration/src/27bccd108cdef30dc0a91ed1968be17bb1e60da4/registration/forms.py?at=default#cl-45 https://bitbucket.org/ubernostrum/django-registration/src/27... Looks like that's the only place that enforces duplicate usernames.

StavrosK 14y ago

I should write it up as a blog post. Basically: 1) Create the new User model, and create a schema migration for it. 2) Create a data migration to copy every piece of data you have in your users and profiles over to the new User model. 3) Add ForeignKeys to all your models that reference either the old User model or the Profile. 4) Add a data migration to copy every reference to the old User/Profile from every other model to the new FKs, to point to the corresponding NewUser model. 5) Remove the old FKs with a schema migration. 6) Rename all the new FKs to the old names, create a schema migration, go into it and turn all the delete/creates into column updates. 7) Revert your code to your last commit because you noticed you screwed something up and you can't reverse it now. 8) Done.