Multiple user types
Sander
I'm kinda new to Django, and just finished reading the Django book.
Now I was wondering the following when it comes to user management.
In the Django documentation I found that storing additional
information is acomplished by writing a new model and add a foreign
key to the user.
Then in the settings file add a reference to the model by adding:
AUTH_PROFILE_MODULE = 'app.UserProfileModel'
So far, so good. But now I want to have two (or more) user types on my
site with each their additional info. lets say I have a user
representing a Teacher wich I want to store the additional info 'age,
gender, experience_years' AND a user representing a student which I
want to give the additional info 'student number, class'.
What is the best practice to accomplish this. Is it somehow possible
to add additional information to a group of users?
Thanks very much.
bruno desthuilliers
> Hello everybody,
>
> I'm kinda new to Django, and just finished reading the Django book.
> Now I was wondering the following when it comes to user management.
>
> In the Django documentation I found that storing additional
> information is acomplished by writing a new model and add a foreign
> key to the user.
> Then in the settings file add a reference to the model by adding:
> AUTH_PROFILE_MODULE = 'app.UserProfileModel'
>
> So far, so good. But now I want to have two (or more) user types on my
> site with each their additional info. lets say I have a user
> representing a Teacher wich I want to store the additional info 'age,
> gender, experience_years' AND a user representing a student which I
> want to give the additional info 'student number, class'.
I solved this using a BaseProfile model and specific "user type"
models inheriting from BaseProfile. It can be a bit of a PITA
sometimes - you'll have to do stuff like
user.get_profile().student.student_number or
user.get_profile().teacher.gender - but it works.
Sander
Thanks!
On 17 feb, 09:53, bruno desthuilliers <bruno.desthuilli...@gmail.com>
wrote:
David De La Harpe Golden
> user.get_profile().student.student_number or
> user.get_profile().teacher.gender - but it works.
I'm becoming pretty vague on what advantage the userprofile mechanism
offers over other one to one fields to User. Is it just a convention at
this stage (now that one to one fields don't do dark magic to primary keys)?
Sander
fields?
Interrested in your ideas.
On 17 feb, 14:13, David De La Harpe Golden
David De La Harpe Golden
> Can you explain yourself a little bit more about the other one to one
> fields?
Well, django has a "OneToOneField" field type, that is like ForeignKey"
only assumes the two models are, well, one to one. And thus, the
generated reverse relation accessor returns a single object rather than
a set of objects, which is mildly convenient over being careful to keep
that true yourself. It was (and is) used to implement django's
multi-table inheritance. When you use that, there's an implicit
OneToOneField defined, basically.
http://docs.djangoproject.com/en/1.1/ref/models/fields/#onetoonefield
Until [mumble] ago, it also implied primary key as it was geared
towards inheritance.
class Student(models.Model):
user = models.OneToOneField(User, related_name="as_student")
class Teacher(models.Model):
user = models.OneToOneField(User, related_name="as_teacher")
u = User.objects.get(username='whatever')
Student.objects.create(user=u)
Teacher.objects.create(user=u)
u.as_student
u.as_teacher
This does mean Users can "be" both Students and Teachers, which you may
or may not want.
You have to define a signal handler to create UserProfiles if you want
them autocreated - so you can just as easily make the signal handler
create various other models with OneToOneFields if you want.
... So one advantage of multi-table-inheriting from (as Bruno
suggested) a profile (or indeed OneToOneField-ing to a created profile
rather than user which is highly similar) rather than doing that is that
it avoids "polluting" the namespace in User ("owned" by django, not
you...) with reverse relation accessors. OTOH it means every access
becomes that bit longer to write out, as you saw from Bruno's example.
... Just having the UserProfile mechanism as a "common idiom" might be
useful, as guide to people wanting to do "userprofiley things", and if
you're doing a "userprofiley thing", and _not_ using UserProfile, you
might be being needlessly obscure for developers joining your project...
ALJ
with inheritance.
ALJ