My personal preference is to just create a new model class with a ForeignKey field pointing to the User model with unique=True set. That way you can extend the User object in as many different apps as you want. For instance in a forum app you could have a model tracking the number of posts a user made and in a blog app you could have a model tracking the number of comments the user has made.
The advantage of this method is that you can seperate all the data you store about a User into different apps rather than just having one site wide UserProfile model which would need to store lots of different types of data that would probably benefit from being stored in seperate models. On 21 Aug 2011, at 14:52, Matt Schinckel wrote: > You haven't really provided a reason why to 'do it the django way', rather > than inheriting from User. > > You do make a valid point about the separate data being in a different table: > the difference would be that with using UserProfile, you need to either do > the .select_related() yourself, of have a second db query when you do a > .get_profile(). With the inheritance method, django will do the joins for you. > > This may actually bite: there are some circumstances where a join is more > expensive than a second query. In either case, right now is probably not the > time to worry about it. Wait until it becomes a performance issue. -- 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.
