First of all, congratulations to the team on reaching 1.0. It looks like a lot of good features landed in time.
One thing that I still find messy, though, is the whole user/profile thing. Having separate models for users and profiles has a number of drawbacks: * extra DB hits * having to traverse either the user attribute or the result of the get_profile method * by default, the user information is split across two models in the admin interface * the user, the profile, or both might need to be saved depending on which information was edited * uncertainty over whether other models should have user or profile as FK * uncertainty over whether friendship relationship should be on user or profile Some people have suggested that the qsrf inheritance be used to create a model derived from User, and a custom authentication backend written that creates and returns instances of the appropriate model. I'm fairly "meh" on that idea (and ORM-based inheritance in general, but that's another story), and it doesn't seem to be a solution supported by the official documentation. What I'd like to see is an easy, supported way of specifying the name of the user model in the settings file, thereby avoiding all of the above complexity. There are a few places where hard-coded references to django.contrib.auth.models.User would need to be replaced, but I can think of a couple of ways of doing that, including backwards- compatible ones. Can anyone think of any reasons why this would be a bad idea? I'd certainly be willing to provide a suitable patch. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
