Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Django developers
Home
+ new post
About this group
Join this group
Message from discussion auth.User refactor: reboot
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Donald Stufft  
View profile  
 More options Mar 16 2012, 1:36 pm
From: Donald Stufft <donald.stu...@gmail.com>
Date: Fri, 16 Mar 2012 13:36:41 -0400
Local: Fri, Mar 16 2012 1:36 pm
Subject: Re: auth.User refactor: reboot
Print | View thread | Show original | Report this message | Find messages by this author

On Friday, March 16, 2012 at 1:29 PM, Tom Evans wrote:
> On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss <ja...@jacobian.org (mailto:ja...@jacobian.org)> wrote:
> > Hi folks --
> > […]

> I'm not in favour of pluggable user models, as for me, they solve the
> wrong problem. A pluggable user model has to be set up by the project
> developer, whilst the attributes an app may need are specified solely
> by the app developer.

> If a project developer decides to add a 3rd party app to his project,
> where do the user preferences for that app live? Does the user model
> automatically get expanded with the extra fields required by that app?
> It all seems icky to me.

> To my mind, User + app specific user profiles are the correct
> approach, plus fixing the current minor issues with d.c.a., and
> providing tools and documentation to allow users to manage that
> change.

> Put another way, what does a pluggable user model get us? What is the
> big selling point, apart from being able to specify arbitrary columns
> to appear in auth_user rather than myapp_userprofile.

In the current situation it would allow overriding the username field to be longer in order to
use say an email address. But that particular issue is sort of a red herring to the larger issue
that if what you want from the User model doesn't fit the current User model, your options are
A) throw it out (which means you basically can't use any third party apps that deal with users), or
B) monkey patch it/hack around the limitation.

The model is completely inflexible. Which is fine when you just want to _add_ information, in those
cases you can just use a profile. But what about when you want to modify one of the assumptions
that the user model makes? (in the above example, what constitutes a valid username).

In my mind unless the User model becomes nothing more than an intermediate model that other models
FK back too (with no real attributes of it's own) you are always going to have an issue where someone
wants to modify some part of it and can't without doing something really hacky. And I think that having
a situation like that is far worse that pluggable user models.  

> Cheers

> Tom

> --  
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com (mailto:django-developers+unsubscribe@googlegroups.com).
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google