On Apr 3, 3:35 am, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > Hi folks -- > > I've written up a proposal for how *I* would like to address refactoring > auth.user:https://gist.github.com/2245327. > > In essence, this does two things: > > * Vastly "prunes" the required fields on auth.user. The only things left are > an "identifier" (which could be username, email, url, uuid, whatever), and a > password. > * Introduces a new "profile" system that provides a way to contribute extra > related fields. Multiple profiles are supported, along with some syntactic > sugar for dealing with multiple profiles in a reasonably reusable way. > > And that's about it. I'm deliberately trying to find a middle ground between > "do the minimum to allow people to move on" and "throw out and rewrite > django.contrib.auth entirely". I'm not expecting everyone to be thrilled by > this idea, but I'm hoping that this is "Good Enough" for almost everyone. > > For more please see the document. Please do try to read the whole thing: I've > had a few rounds of feedback incorporated already, and there's even an FAQ at > the end. > > I'm not using BDFL fiat here, at least not yet. This is a proposal, and I > very much want to hear feedback, objections, and alternatives. I'm > particularly interested in hearing from people who've got complicated auth > needs and think this absolutely won't work for them. > > I *have* reviewed all the other proposals and I'm between -0 and -1 on all of > them. This means that if you don't like my proposal, you'll probably have to > come up with a complete *new* idea to have any chance of getting my vote.
FWIW I am +1 on this proposal. This is assuming that forms, queryset handling of the data and so on actually work correctly and nicely. I don't see a blocker in those areas, but before the code is actually written and tested it is impossible to say if there will be problems. Devil is in the details and all that. I hope this will not result in hacks to allow .filter(data__) and so on. I believe we should aim for as generic solutions as possible. If we do hacks just for the User model, they _are_ going to cause problems later on. Most of the features needed would be neat to have regardless of the User refactor. Custom lookups per model/field for example would be _really_ neat feature. The downside of aiming for generic solutions is that we once again get into the situation where User refactor is blocked by implementing foo, bar and baz before it. I believe this is the right way forward. Multiple profiles makes sense in the SQL world, and in the NoSQL world you would just embed the profiles into the User document. I don't believe performance will be a problem in practice, at least as long as you don't add too many different profiles to be loaded by default. The most common use case will just get better support: you have user profile containing three fields, and then you have all your local fields defined in one profile. As now, you have profile + user, now they just model your data properly. I don't see a proposal of how __unicode__ is going to be handled (the Hello, UserName requirement). My proposal: go through the profiles in the order they are defined, and pick the first one having __unicode__ defined as the default __unicode__. If there is no such profile, return identifier. - Anssi -- 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.
