User profiles: pros, cons, pitfalls

It's no secret that working with user profiles in Django can only be called a misfortune. We all faced with the solidity of the model auth.User , an inadequate set of fields in it, as well as all the tricks to which it was necessary to resort.



Everyone had to pervert: not only junga users, but also its core developers themselves. Remember, for example, how in Django 1.2 it suddenly became possible to use dog characters (@) and username in the username field? Do you know why? So that you can use e-mail addresses as logins.



We, ordinary users, also lived hard. In order to change the user profile, adding to it some interesting fields - a seemingly ordinary thing, right? - had to act in different ways.

• Take inheritance , for example. It was required to create own model inherited from auth.User ...
  
  ')
  
  

   # models.py from django.db import models from django.contrib.auth.models import User class MyUser(User): birthday = models.DateField() 

  
  
  ... and write a middleware that would replace the class for request.user . Or not, and AUTHENTICATION_BACKEND . Never mind :)
  
  
  
  The advantage of the scheme was that our “client” code (that is, the code of the projects) did not become complicated, we just worked with our user, as with the usual jung code.
  
  
  
  The main disadvantage of such a scheme is that when models are inherited, not one table in the database is filled, but two: the original Django_auth django_auth and our ourproj_user , which has a foreign key on django_auth . Yes, model inheritance in Django is just OneToOneField with some additional attributes. Want to use - keep in mind.
  
  
  
  
• A no less famous crutch proposed by the creators of Django is the so-called profile model . We were offered to create a Profile model with a one-to-one auth.User on auth.User ...
  
  
  
  

   # models.py from django.db import models from django.contrib.auth.models import User class Profile(models.Model): user = models.OneToOneField(User) birthday = models.DateField() 

  
  
  ... and then add something to settings:
  
  
  
  

   AUTH_PROFILE_MODULE = 'accounts.Profile' 

  
  
  After that, in the client code, we could work with the profile:
  
  
  
  

   profile = request.user.get_profile() profile.birthday = datetime.today() profile.save() 

  
  
  Plus, I don't know about such a scheme :) maybe any set of any fields with any name? With minuses all is more transparent:
  
  
  • complexity of support: we now have not one object to edit, but two. We must not forget that we change the date of birth of the profile , and, for example, the password of the user . No wonder and confused.
    
    
    
    
  • non-targeted waste of resources: every call to get_profile() causes a query to the database. On pages where the user instance is only one (editing, for example), this is not a problem. If such a thing is, for example, in the comments, the result will be deplorable. Of course, select_related() , as you understand, will not save, because not User depends on Profile , but vice versa.
    
    
  • and still have to do everything hands! Creating a User model does not mean that the associated Profile model will be created automatically. But when accessing get_profile() for a newly created user, an exception will be thrown - no doubt here. And although this trouble is treated in a few lines with the simplest signal,
    
    
    
    

     # profile.models from django.db import models from django.contrib.auth.models import User class Profile(models.Model): '- ' def create_profile(sender, **kwargs): if kwargs['created']: Profile.objects.create(user=kwargs['instance']) models.signals.post_save.connect(create_profile, sender=User) 

    
    
    still annoying her need to "manual" solutions.
• Mankipatching , that is, changing the behavior of the program without rewriting the code. After the application was initialized, in some place of the project (as a rule, in the root urls , settings or models specially instituted application), we wrote the code modifying our User:
  
  
  
  

   # monkey_patching.models from django.db import models from django.contrib.auth.models import User User.add_to_class('birthday', models.DateField() ) 

  
  
  Plus, as with inheritance, ease in the client code. Cons - non-obviousness. With magic, as you know, you need to handle very carefully, because you can accidentally redefine some thing, and pop up in a completely different place. On the other hand, if very carefully, then why not?

By the way, about monkeys ...

The guys who gave the world the legendary sorl.thumbnail , once again distinguished themselves and produced at the expense of another killer thing. Meet: django-primate , an application that using monkeypatching methods (primates and monkeys, do you feel the correlation?) Makes it very easy to turn your own model into auth.User . That is, in Russian, to make a profile of the required fields.



Getting started is easy enough. First you need to put django-primate. Possible with PyPI:

 pip install django-primate 

... or the latest version from their repository:

 pip install -e git+https://github.com/aino/django-primate.git#egg=django-primate 

You need to call the patch at the start. The creators recommend using it in manage.py

 #!/usr/bin/env python from django.core.management import setup_environ, ManagementUtility import imp try: imp.find_module('settings') # Assumed to be in the same directory. except ImportError: import sys sys.stderr.write( "Error: Can't find the file 'settings.py' in the directory " "containing %r. It appears you've customized things.\nYou'll have to " "run django-admin.py, passing it your settings module.\n" % __file__ ) sys.exit(1) import settings if __name__ == "__main__": setup_environ(settings) import primate primate.patch() ManagementUtility().execute() 

it now remains only to indicate in the settings class of the model that we want to use

 AUTH_USER_MODEL = 'users.models.User' 

... and you can start to invent models:

 # users.models from django.db import models from primate.models import UserBase, UserMeta class User(UserBase): __metaclass__ = UserMeta birthday = models.DateField() #    ? 

Now every time a project component django.contrib.auth.models.User , it will receive the users.models.User model. The reverse is also true. The admin patch will be patched automatically, no special actions are required to connect it.



By default, the django-primate user model has the following differences from auth.User :

• The fields first_name and last_name , but name added;
• The maximum length of the username field is 50 characters ( auth.User were 30 in auth.User )
• A unique index has been added to the email field.
• The get_profile method returns self , so don't worry about code using user.get_profile()

For the rest, the primate user model walks like a duck, floats like a duck and quacks like a duck behaves very much like the original source.



Of course, you can use absolutely any set of fields, but in this case there is a risk that there will be incompatibility between third-party applications, so the username , password and email fields are best not to rename.



One more thing: for compatibility with jung, the primate will model the model so that its app_label will become not users (as in the example), but auth . This is especially true for South users who may not understand for some time why

 ./manage.py schemamigration users --auto 

does not create any migrations.



However, everyone can get acquainted with the README, which I oochen translated freely. If I missed something, made a mistake or made an inaccuracy, write in comments or share your thoughts on the subject.



Thanks for attention :)