Until you install some third party app that accesses User.objects.all() and then suddenly nothing works as it's supposed to.
You can access the User object from its related UserProfile instance and do everything you say from there instead of breaking the convention. Nobody's stopping you from writing an abstract BaseUserProfile model with an FK to User and custom UserProfile subclasses. I just don't see any advantages in going down that path. Because how will you access every user if you ever need to? What if someone gets promoted? How will you separate view from model logic? Are you going to rewrite forms for every user class? That's probably going to be hard to maintain. FWIW, profiles are the canonical solution. They are also the only elegant solution, at least until the app loading branch lands on trunk, which should then allow you to register a different class as User. But that won't happen any time soon.. Cheers, AT On 8/18/11, Matt Schinckel <m...@schinckel.net> wrote: > Lately, I have been looking at using subclasses of auth.User as a way of > segmenting users. > > This appears (to me, at this stage, anyway) to have several advantages over > using the UserProfile approach. > > * You can have extra attributes on the subclass. For instance, one set of > users belong to a Company, and I can do this FK relation from the subclass. > Similarly, I can have a date_of_birth field that is attached to the user, > rather than the UserProfile. From a performance perspective, this doesn't > make a lick of difference, as a subclass of a concrete class still has a > join anyway. > * You can easily have different user classes appear differently in the > admin. > * You can have different relationships between particular User types and > other objects. For instance, a Staff user may 'work_at' a Location, but an > 'AreaManager' may have a 'manages' relationship to an Area. You can still do > this with auth.User, but every user will have every relationship. > > The biggest helper for this was to have an authentication backend that > automatically selects the subclass, so that you no longer get a User object > in request.user, but whatever you want. > > A drawback is that you can't easily change the field types: email, which I > use for authentication, needs to be unique. You can handle this with > validation checking on forms, but that requires you to remember to build > this into your forms. The other way is to monkey-patch the User class > directly, and manually fix the database to not allow duplicates on the email > column. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-users/-/Y6qCTdPzU9sJ. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- Sent from my mobile device -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
