Use one to many field or many to many field On Wed, Nov 9, 2016 at 3:06 PM, Melvyn Sopacua <[email protected]> wrote:
> Hi, > > > What is the current canonical way to handle multiple user-profiles in > > Django? > > it highly depends on how you see these objects: > > 1. different types of users (requirement: a user can only be one type) > 2. one type of user with additional information from different sources > 3. different types of users, but users can be multiple types > > Obviously the third is the hardest. > > > On Tuesday 08 November 2016 16:54:43 Victor Hooi wrote: > > > For example - say you have "Teachers", "Students", "Parents" - you may > > have slightly different fields for each one and/or different > > behaviour. Students will have things like grades, Parents may have > > 1-to-many Students etc. > > Here you clearly think of them as types, instead of Humans and yet they > can fulfill multiple roles. It also doesn't matter what is in the > profile, as long as you don't care about enforcing required information > at the model layer. > You can make one profile model with the union of all fields and use > group membership to enforce requirements. So a Human which is member of > the Teachers group must have "date_employed" filled in while Student > must have "date_enrolled". Similarly, you can use group membership to > determine what information to show. > Splitting them out in different profiles is a matter of preference and > optimization, not of design. > > > The docs mention using a django.db.models.signals.post_save > > <https://docs.djangoproject.com/en/1.10/ref/signals/#django.db.models. > > signals.post_save> signal on User, but I'm guessing that won't work > > here if you have multiple types of users. > > When you have multiple *profiles* this will work just fine. It's also > not a big problem to solve, because user creation and updating is not an > uncontrollable process like the docs suggest. > User creation via commandline or automated process really only happens > in tests and backup restore procedures. > > In production it's your job to properly set permissions for meddling > with users in the admin and to provide forms that include relevant > profile information. When providing good forms the signal is actually > disruptive: you already have the information available, you save the > user then save the profile information. Having a signal fire that > doesn't have access to that profile information is not very useful and > can lead to validation errors simply because the handler doesn't have > the context. > > > Or are you better off subclassing > > django.contrib.auth.models.AbstractUser? (I get the impression using > > profile models is less invasive). > > The case for subclassing is really only one: > Do you not have the right information in the standard user model to > authenticate the user? > Highly specialized cases aside, it's better to use profiles. > > A prominent example for not having the right information is when > authentication happens with SSL certificates rather then > username/password. Another is having different authentication servers > and what server to use is depending on a field that isn't in the user > model, like "faculty" or "signup_date.year". > > Hope this helps, > -- > Melvyn Sopacua > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/1678108.SszHfPmntC%40devstation. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAAcanssSwCF48tS_HKisWfr-QRjCTtQFUL8uPZHqN1xqNr3NPw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
