On 03/18/2011 08:09 AM, Alexander Schepanovski wrote: > I think using subclass of User model for your fields has the same > flexibility as separate profile model (since you can have only one).
You can have multiple subclasses of the User model (not that I recommend subclassing). > contrib.auth can be fairly simply adjusted to use custom User model > from settings instead of always using its own User. Yes, it could, but the entire ecosystem of reusable apps with FKs pointing to contrib.auth.models.User can't. > In that sense I am totally for homogenization because it will make > code cleaner and eliminate unnecessary sql request not because of > serialization. Subclassing doesn't solve the extra SQL request unless the base User model is turned into an abstract model, which would completely break third-party FKs. "Custom User model" is definitely a problem I'd like to see solved, but to do it in a way that's backwards-compatible and allows reusable code to point FKs at User is a difficult problem that will require adding significant new indirection capabilities to the ORM, and no-one has yet proposed a full solution AFAIK. > Such code is really an eyesore: > first_name = user.first_name > middle_name = user.get_profile().middle_name > last_name = user.last_name I agree it's ugly, but if it bothers you it's fairly easy to wrap it up into properties on your profile that proxy to the User model, and then just always use your profile (you can even add a middleware that creates a lazy-profile attribute directly on the request, if you want). > What do you do in such situation? Create a profile class containing > all required fields? And then if you update some app you need to > update your composite UserProfile model? Don't use AUTH_PROFILE_MODULE or .get_profile(). As far as I'm concerned they bring almost nothing to the table except for the "there can be only one" restriction, and I'd be just as happy to see them deprecated at some point. The only justification I've heard for them is that they allow reusable code to access the user profile, but I'm not sure what reusable code is going to usefully do with a custom profile model when it has no idea what properties it has. Just use OneToOneField and the regular ORM access descriptors, and you can have as many "user profiles" as you need. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
