Django: Getting Started Transcripts
Chapter: Users and Account Management
Lecture: Customizing the user model
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
You've already seen the user model that comes with Django. But what if you want to do something that the default model can't?
0:07
Well, you have three choices, if you only want to change the behavior of methods
0:12
but not the underlying data structures you can inherit from user and change your configuration to point to your new object.
0:20
I've never personally done this one. The more likely case is you have additional data you want to associate with the user
0:27
Django calls this a user profile object, You create a user profile object like any other model.
0:35
The only requirement is that it has to be a 1-1 relationship with the user model object. Because the relationship is 1-1,
0:44
Django can set up references from the user to the profile and back again. That way, if you're accessing the logged in
0:51
user from the request object in a view, you're just a d reference away from your extended data. In older versions of Django,
1:00
this was the only real choice. So it's a common approach. But now there's a third option which is to completely replace the user object.
1:10
This requires a new storage class with some configuration to tell Django to use it and a new manager class in that you'll have to implement your
1:19
own create user method amongst some other things. There's a bit more work to get this going.
1:26
But it allows you to do fancy things like change what field is used for login
1:29
If you want your users to log in with an email address instead of a user name. This is the approach you need to take.
1:38
If you've got an existing user base switching from one of the first two modes to the third can be problematic.
1:42
It is possible, but you've got to be very careful. Adding a profile late in the game is no big deal changing how your users log in is going to
1:51
be a problem for the code and for your users. It is best to make this decision up front and stick with it if possible.
2:00
Let's look a little further at that second option, creating a user profile object. The only tricky part here is when the object gets created.
2:09
As the profile object has a 1-1 relationship with the user model, the user model object has to be created first. To make this more complicated,
2:18
you have to consider that different ways the user model object can be created. You might have a self sign up page.
2:25
There is also the Django admin or you might be doing batch imports, each of these is subtly different. You have to make sure that however,
2:34
the user model gets created, the profile object gets created at the same time.
2:39
Enter Djangos signaling system, you can register a function to be called when certain events happen in the system.
2:47
One of the events you can register for is the creation of an object. Like the user model. There's a big exception case here.
2:55
This only works if you're using Django's code, certain bulk database activities are done in the sequel layer and won't trigger these kinds of signals.
3:04
If you stick to the Django admin and use the user models, create user method, you'll be fine. In addition to adding event handling code.
3:14
You also want to make sure your fields are available in the Django admin. There is a way to create sub areas in an admin page that you can take
3:22
advantage of and embed your profiles fields in the user model edits page. Let's go write a user profile.