On 18 мар, 21:22, Carl Meyer <c...@oddbird.net> wrote: > 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.
I meaned making User model abstract the same way Tom Evans demonstrated. It can be still used with profiles. > 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). One should fix problem not hide it. > 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. I always construct single profile model for a project with fields needed by all its apps. That's why I make my reusable apps provide mixins and abstracts of profiles. I think profile model is redundant itself, more of them even worse. It complicates code in many ways, constructing a form for registration and edit profile is a good example. -- 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.
