Yeah, a mechanism where you can subclass User **and use your subclass in lieu** is quite similar to what I suggested and, I agree, solves the problems I raise.
A subclass is also going to be substantially cleaner than having a new special way to add fields. Then we just need a Django setting to specify the User subclass, and which would check to ensure that any expected fields/methods are appropriately set (e.g. that it really does subclass User, or if it doesn't, that it duck types it comprehensively). Best Regards, Luke On March 16, 2012, at 13:15 , Donald Stufft wrote: > On Friday, March 16, 2012 at 2:08 PM, Luke Sneeringer wrote: >> Disclaimer: I was up really, really early this morning, so please bear with >> me if I sound somewhat incoherent... >> >> On March 16, 2012, at 12:29 , Tom Evans wrote: >> >>> On Fri, Mar 16, 2012 at 4:53 PM, Jacob Kaplan-Moss <ja...@jacobian.org> >>> wrote: >>>> Hi folks -- >>>> […] >>> >>> I'm not in favour of pluggable user models, as for me, they solve the >>> wrong problem. A pluggable user model has to be set up by the project >>> developer, whilst the attributes an app may need are specified solely >>> by the app developer. >>> >>> If a project developer decides to add a 3rd party app to his project, >>> where do the user preferences for that app live? Does the user model >>> automatically get expanded with the extra fields required by that app? >>> It all seems icky to me. >>> >>> To my mind, User + app specific user profiles are the correct >>> approach, plus fixing the current minor issues with d.c.a., and >>> providing tools and documentation to allow users to manage that >>> change. >>> >>> Put another way, what does a pluggable user model get us? What is the >>> big selling point, apart from being able to specify arbitrary columns >>> to appear in auth_user rather than myapp_userprofile. >> >> I personally find the User/Profile mechanism in Django to be quite awkward, >> to be honest. It's certainly not the end of the world, but it'd be nice if >> it was...less contrived feeling. >> >> I have an interesting suggestion/compromise: What about a mechanism that >> allows the app developer to *add* fields to the User model, but not change >> (or remove) existing keys? From my vantage point, this would have nearly all >> of the benefits of a pluggable user model with almost none of the drawbacks, >> and it would feel much more straightforward than the current mechanism. >> There may be some reason that I'm missing as to why this is foolish, though. >> >> Here's my hit list of perceived benefits: >> 1. It regains the efficiency of a single table (which is minor, to be sure, >> but since Jacob already brought it up...) > This issue isn't as minor as one might think I don't believe. I've recently > started using the fetch_related thing (which would be the only way to prevent > N queries when trying to select a bunch of users + their profiles) and on a > table with 20k entries (this isn't User related) where the entries are fairly > large the processing time to fetch them all was very significant. This effect > would increase with Tom's per app profile issue. >> >> 2. It allows app developers who just need a little bit more than what the >> User model does to add their custom fields seamlessly. This would mean, for >> instance, > The subclassable user model that django-primate uses solves this as easily as > it does the base fields. >> >> a. That the admin would just magically have the new fields in the User form, >> instead of having to either plug in a custom form, set up a separate >> ModelAdmin for your profile, or whatever else. For registration, we could >> offer two stock forms (one minimalist one, and one complete one that just >> blindly uses every field we don't know we want to exclude (e.g. is_staff)). >> If neither form works for the end developer, then they write and use their >> own. >> >> b. That the end developers don't have to write repetitive glue code on every >> one of their projects to make their profile models work. (Why do I have to >> write a signal to auto-save a profile object on User object save every time, >> for instance?) >> >> 3. We don't have myapp_userprofile. This is kind of a big deal to me, >> because in most of my projects there is no "clear" / "correct" place for >> this model to live -- there's no single app that handles users, because >> that's what django.contrib.auth is supposed to do. Getting these arbitrary >> columns into auth_user is a nice categorization win. >> >> If I understand this correctly, we avoid the following drawbacks of a fully >> pluggable system: >> 1. Apps can still be written to expect certain fields on User to exist, >> because the customization only allows the addition (not alteration) of >> fields. > This is somewhat of a red herring I think. With any pluggable system you'll > have a minimal set of required attributes. This minimum set of required is > going to depend greatly on what apps you have installed. Some sites the only > minimum would be the fact that a user model exists at all, some would require > username, email, first and last name. >> >> 2. We aren't expecting nearly every Django installation to write their own >> User model just to make a small addition to what stock Django offers; if you >> want just an extra field for birthdate, you don't write an entire custom >> user model; you just add the field. Since "I just want a few extra fields" >> is (other than the email address / username snafu) probably the most common >> need for auth, making this easy is a big win. >> >> What this does *not* solve is a situation where there's a field on User >> that's somehow wrong, such as the 30/75 character limitations on usernames >> and email addresses. Presumably this is done as part of a completionist >> revamp where we also fix those problems. > A subclassable usable model similar to primate does solve this issue. >> >> Best Regards, >> Luke >> >> P. S. I've lurked on the Django dev list for a long time, but never gotten >> my feet wet. That said, the improvements to auth being discussed are >> something I really want, and I want them enough to help out non-trivially if >> afforded the opportunity. I was planning on emailing Carl and Russell to >> pick their brains later, but maybe it's worth a public statement. >> >> -- >> 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.
