Shawn has hit the "whys" fairly well -- the three arguments he gave are definitely the top three. Covering authentication via other sources (e.g., OAuth, etc) was another use case (although this use case would also be a candidate for a plugin app)
Taking avatar as an example -- I'd frame the question like this:
Taking avatar as an example -- I'd frame the question like this:
* Could your project function without the concept of an avatar? You might need to use some other drop-in graphic in place of an avatar instead, but would the absence of an avatar fundamentally stop other parts of your site from working? On your site, is the concept of an avatar so tightly bound to a User that there's no practical way you could put that functionality in a separate model? Again, without knowing specifics, I can't say for certain, but generally, I'd say the answer is no - The fact that the default new user won't have an avatar is proof of this. This means that the avatar is a good candidate for *not* being on your User model, and being kept in a separate avatar management app.
* In practice, does the database overhead for your website mean the join to the "avatar" table is prohibitively costly? Is this something you can't overcome by caching the path to the avatar graphic on a per-user basis? This is something I can't answer canonically without seeing your server logs, but I'd be willing to wager the answer is "probably not".
Yours,
Russ Magee %-)
On Thu, Feb 28, 2013 at 1:05 AM, Doug <dmeehan@gmail.com> wrote:
Russ,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?--To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
You received this message because you are subscribed to the Google Groups "Django users" group.
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.
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