Amit Upadhyay wrote:
> On 5/9/07, *Vinay Sajip* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> One simple problem with Amit's approach, as written, is that you have
> to deal with "fuser" and "duser", which feels a little kludgy (I
> realise he was just demonstrating the concept, but the problem still
> remains that you want to think of all the profile information as just
> part of the user model. Is the intention just to avoid saying
> user.get_profile().xxx? Can't this be done by judiciously overriding
> __getattribute__ in User, to delegate to a profile if one is defined?
>
> Agree with you. I was suggesting this solution as a part of multiple
> type of user scenario, where profile itself would be different. For us,
> we have endusers, and businesses, and we require different kind of
> profiles for both of them. .get_profile() does not handle this situation
> (AFAIK).
My problem with the get_profile or any of the proposed fixes is that it
generates a lot of extra queries which one would normally not have.
for user in User.objects.all()[0:10]:
print user.username, user.get_profile().birthday
will get you 10 queries extra, no matter how much select_related you
use. In some cases -but not always- you can do:
for profile in Profile.objects.select_related.all()[0:10]:
print profile.user.username, profile.birthday
but doing the query like this doesn't always work!
In my opinion there's only one easy solution which doesn't create
ridiculous overhead and that is to be able to add fields to the User
model without having to hack the actual code of the User model. Does
anyone agree with this?
- bram
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
