On Tue, Apr 10, 2012 at 6:04 PM, Alex Ogier <alex.og...@gmail.com> wrote: > Hi Tom, > > The best rounded description with pros and cons is Solution 2a on > https://code.djangoproject.com/wiki/ContribAuthImprovements > > You are correct that I am primarily thinking of pluggable authentication > when I think of this new user model. The reason is that there is nothing > stopping you from continuing to place app data outside the user model as has > been standard for a while now. For example, there is nothing stopping you > from using the following pattern in you app's view: > > if request.user.is_authenticated(): > try: > prefs = GalleryPref.objects.get(user=request.user) > except GalleryPref.DoesNotExist: > prefs = None > > That is, unless you have a reason that your particular data should be > eagerly loaded on every request there is no reason to require it on the > user. In fact app developers are incentivized to keep their data separate in > order to remain compatible with the default user. > > The solution isn't perfect, it does in fact provide some barriers to this > pattern. The Gallery app must explicitly choose to foreign key to > settings.USER_MODEL, and once they do *changing* which model the setting > points to requires a migration of your table. These are both real issues, > but I don't think that user model bloat will be because there is a > straightforward way to work around it if it does prove to be an issue for > any particular project. > > The only thing this proposal kills is magic proxying back from user > attributes. If you really wanted to, you could roll your own proxy > attributes to app fields, after all you control the entire user class. > > Best, > Alex Ogier >
Hi Alex, thanks for that. I think that a lot of this information should end up in the revised docs, showing patterns on how to (correctly) use the new features, when to add fields to user and when not to, etc. and we should be fine. I wasn't that interested in the magic proxying. Eventually, all magic dies and has to be removed, so it is better to just be explicit about what is happening. Cheers Tom -- 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.
