Hi everyone, I'm a student at Brandeis University, and I'm actually interested in working on an 'enhanced auth.user' for GSOC 2012. I don't have a formal proposal yet, but I drafted up the main idea of what's I'm planning in a google doc: https://docs.google.com/document/d/1HOHAs-mzwyNuZR8tVjGFXkt5XI64l7sOL_ao5FqNRZc/edit?pli=1.
Once I work out some more of the details, I'll propose it in a separate thread and see where the discussion takes it. From playing around with the current code and making slight modifications, it seems like the idea will work. Michael Keselman On Fri, Mar 16, 2012 at 2:23 PM, Luke Sneeringer <lukesneerin...@gmail.com>wrote: > 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. > -- 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.
