Thanks so much for your reply. I guess the confusion is around the subjectivity of what is considered "identifying the user". In my case, the additional data is not application related, it is project related and would be part of a "Profile" that is used throughout the site across many applications.
I guess the more specific question would be: should user data be limited to data necessary for _authentication_. This makes sense when you take into account that the app it is a part of is "auth".
So when you say "core identifying information", do you mean authentication information? In this case, avatar would not fit the description, in much the same way that bio or location would not.
Perhaps I am overcomplicating things, but I want to create a solution that is as simple as possible without limiting flexibility.
I guess what would help is an idea of what the primary reason was for the change to the user model in 1.5. Was it primarily to address the issue of an easier way to provide alternative authentication (versus writing a separate backend)? Or was it also to make it easier to create the concept of a "profile"?
On Saturday, February 23, 2013 11:15:20 PM UTC-5, Russell Keith-Magee wrote:
Hi Doug,Obviously, it's still early days, so "best practice" hasn't really evolved yet. However, based on what I've done with custom user models so far, my advice would be to only put on the User model those things that are part of identifying the User, and maintain a profile for any application-related information that is user specific.So - things like a username, primary contact email address, and an avatar would be reasonable things to have on the User model.Phone number *might* be appropriate for the User model -- depending on whether a phone number is something that is core identifying information for users of you project, or just additional profile information.Things like a biography or current location aren't key concepts for a user -- they're something that can be isolated as part of a profile that is contained in one or many separate user-related applications.In many respects, this is exactly the same story that Django has always maintained -- the difference is that now you have more control over exactly what is considered "core" identifying information.Of course, there are exceptions to every rule -- and the one exception that exists here is performance based. Using profile objects requires the use of a join, and if you're doing a *lot* of profile joins, you might find that denormalizing that join, and putting profile information on the base user object may be worthwhile.However, this should be considered a potential performance enhancement, not architectural advice -- IMHO, most users won't be dealing with enough query volume to be affected by this problem, and should be using profile objects rather than denormalizing.Yours,Russ Magee %-)On Fri, Feb 22, 2013 at 11:10 PM, Doug <dme...@gmail.com> wrote:
I am curious how people are handling the new 1.5 user model with regard to User Profiles. Is it best to add all profile information to a custom user model? Or keep the user model for authentication information only and create a one-to-on or foreign key to a profile model (similar to the pre-1.5 best practice)?In my case, users will have an avatar, a bio, a location, and other profile type information.What are the pros and cons of each approach?--
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 django-users...@googlegroups.com .
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en .
For more options, visit https://groups.google.com/groups/opt_out .
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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment