Hi iPhoneから送信
On 2012/04/06, at 0:29, "Daniel Sokolowski" <daniel.sokolow...@klinsight.com> wrote: > The more I think about it the more it makes sense to me to have a base User > model just a stub with a user Identifier and password field. Sure one could > argue for less ore more fields, but I think the idea > is to pick something that would work in 95% situations and yet be flexible > enough to be extended as you wish. Need to extend to add your own > authorization you create a profile with a FK key to the base model and > a new auth backend. The good part about swappable user models is that you don't need to necessarily fix the model's DB fields in advance. Your identifier and password's length and other properties can be user defined and can be reflected in the DB. Django can also leave migration of user models an data up to the developer so they an use south or whatever to manage the user model since they "own" it. Django Devs wouldn't necessarily need to support a DB table that can essentially never change as is the case currently. Fixing that stuff ahead of time and just making a FK means the user model itself is fixed. I don't want to be able to just add fields. I want to be able to change the primary key to be a uuid, or a email, or use the default auto incrementing integer. I want to be able to use an existing model or DB table and, with some work, plug it into Django auth. Now if I'm customizing the user model itself anyway, why not just tack on whatever other fields I want? I don't need a FK since those fields are on the user model and I can create however many one to one or one to many relationships for "profiles" or user data as makes sense for my project. That may be a lot or it may be zero. (now whether that is realistic given the needs of the admin is a different story) > Perhaps the reason the current contib.auth is still not overhauled is because > it does work for a large number of situation and extending it is relatively > easy. Keep the solution simple - I think we are overthinking it. Sure. I'm not completely discontent continuing to use my own library and simply shun anything that uses auth (besides the admin maybe), but I think Django would be better off with a better auth module. > -----Original Message----- From: Russell Keith-Magee > Sent: Wednesday, April 04, 2012 10:44 AM > To: django-developers@googlegroups.com > Subject: Re: auth.user refactor: the profile aproach > > > On 04/04/2012, at 8:44 PM, Tai Lee wrote: > >> I'm not so sure that it's necessary or even desirable to solve the "general" >> problem of swappable models. If anyone can swap any model by changing a >> setting, that sounds like a recipe for confusion to me. > > Sure, but that's not what I've proposed. A model would only be swappable if > the original app developer declared that model as swappable. An end user > wouldn't be able to arbitrarily decide that they wanted to replace a model in > an app developed by someone else. > > And sure, any feature we add could ultimately end up being used (and > overused) in bad ways. However, that's true of any language or library > feature. Classes, metaclasses, decorators, or any other Python language > feature can be both used and abused, as can Django features like ModelForms > or the internals of the Meta class. > > My point is that there is nothing about this problem that is unique to User. > Django's own codebase contains another example of exactly the same pattern -- > Comments. Therefore, we shouldn't pretend that the solution is User specific. > At some point, we have to just provide enough documentation and guidance to > shepherd people away from bad architectural decisions, and trust that the > userbase will take that advice. > > Yours, > Russ Magee %-) > > -- > 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. > > -- > 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. > -- 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.
