So, after reading this, I think I really only have a couple questions/concerns:
1. What, if anything, is the primary key on the base User model? Is it the identifier? If so, can it be specified as the primary key, rather than unique=True, db_index=True? If it's not the primary key, is it the usual magical id = models.AutoField()? 2. I'm a little nervous about the magical installation of Profile modules -- specifically, what happens once this system has been around for one to two years and we have a ton of these? I'm imagining a situation where there are lots of apps floating around, each with their own Profile subclasses that install behind the scenes when you install the app (and which you may or may not actually realize up front -- yes, a good developer *should* be aware of that, but that doesn't mean they will be...). What happens if a beginner writes everything against user.data['name'], and then installs an app that adds a new name, which is unordered and magically ends up on top, and therefore introduces new, unexpected, and, most importantly, extremely difficult to debug logic errors? I agree with some of the criticisms of swappable user models, but at least the developer always knows what he is doing in that case. In this case, the behavior of your user model can change in unexpected ways when you do something that seems totally unrelated; some code that previously worked might either (1) return different data or (2) suddenly raise KeyError. Perhaps this is the best of bad options. I agree there's a decent bit to be argued in favor of it, but can we figure out a less error-prone way for user.data to work? Honestly, I think it would be less risky to force everyone to write user.admin_profile.name -- it's more typing, but at least it's explicit. The current proposal for user.data doesn't actually pass "refuse the temptation to guess", because it glosses over the fact that developers *will guess* and then their code will stop working after what feels like a completely unrelated change. 3. Might I suggest that the Profile model that the admin requires be called AdminProfile and not DefaultProfile? It's really an admin need more than anything else. Best Regard, Luke On April 2, 2012, at 19:35 , Jacob Kaplan-Moss 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. > > Thanks! > > Jacob > > -- > 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.
