extending the User profile - which way to go?

[Axel Bock]

Hi again,

I will need to add some properties to a user in the future. Now I found two ways of doing it. First, the Django-way (as described in the Django docs). Then I found some other posts from other people, all doing an inheritance of the original User-class and using this one. That seems rather elegant, cause there is one database lookup less necessary per user lookup. Now I want to go a way which is most "Djangonic" - cause I don't want to be stuck somewhere in the future with something that breaks on Django 1.4 or whatever.

Any recommendations from the users here? 

Thanks in advance!

Axel.

[Subhranath Chunder]

My suggestion, do it the Django way. In any case, even if you use the inheritance model, the additional data would be stored in a separate database table, and the data belonging to the super-class would be stored in the main user's database table.

--
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.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

--
Thanks,

Subhranath Chunder.

www.subhranath.com

[Matt Schinckel]

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.

[Simon Connah]

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.

[Shawn Milochik]

Using a OneToOne field does the same thing as a FK with unique set to true, and simplifies queryset syntax.

[Simon Connah]

On 21 Aug 2011, at 19:37, Shawn Milochik wrote:

> Using a OneToOne field does the same thing as a FK with unique set to true, and simplifies queryset syntax.

Good point.

[Axel Bock]

Thanks for all your replies, it makes sense to wait until it's a performance problem :)

Greetings,
Axel.

[Tom Evans]

On Sun, Aug 21, 2011 at 2:52 PM, Matt Schinckel <ma...@schinckel.net> wrote:
> You haven't really provided a reason why to 'do it the django way', rather
> than inheriting from User.

Here is the top one: Extending the user object will make your project
incompatible with 3rd party pluggable apps, as they will not be using
your inherited User model, they will be using
django.contrib.auth.models.User.

UserProfiles, however you implement them, are cumbersome and unwieldy,
but for interop reasons they remain the best way of extending the user
model. Using a separate profile for each app is also wise, since it
separates logically unrelated data.

There is also very little reason to define
settings.AUTH_PROFILE_MODULE apart from making user.get_profile()
work, and if you use a one-to-one field, the difference is then
user.get_profile() // user.myapp_profile .

Cheers

Tom