On Sat, Mar 17, 2012 at 5:59 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > Ok - I've been keeping quiet on this; partially due to the same tone issues > that you've described, but also because I don't have a huge amount of spare > time at the moment, and I don't want to be the person who makes a bunch of > promises (expressed or implied) to work on something and then can't deliver > on those promises.
Hi Russell - could you try to configure your mailer such that it will word wrap at 78 characters. Trying to re-format such a large reply is tricky, so I've chopped most of your email rather than manually word wrapping it myself. > * It's completely backwards compatible. > > If you've got an existing app with normal ForeignKeys to auth.User, > the app will continue to work, without any migrations, as long as > the rest of your project uses auth.User. It will also co-exist with > any configurable app that is configured to use auth.User as the > user model. It will only fall down if you have a configurable app that > uses a different User model (i.e., you can't use a new feature without > ensuring all the parts you need support the new feature). So, what do I do when 3rd party app1 wants a BizarroUser model, and 3rd party app2 wants WeirdUser model? Using the two together as a mix-in would cause problems with any name/definition clash. User profiles solve the issue of app specific data in a better way than specifying additional fields on a a base user object, particularly as the number of apps increases. Whilst there is an additional cost in joining to the user profile table, typically in app1 you only need app1.UserProfile, and not appN.UserProfile. Profile settings shared amongst many apps are 'site specific' and live on the 'blessed' site user profile denoted by AUTH_PROFILE_MODULE, and accessed via User.get_profile(), which caches the profile. To me, anyone wishing to add fields to User should be adding them to their site profile. Just while we're talking about profiles, obviously the additional join to access the profile has costs, but sometimes the cost can appear higher than it actually is. If you have 20 distinct profile classes, one for each pluggable app to store it's data, and you only require access to one of them - which is likely, each app will only know about its own profile - then the cost of the join may be similar to the cost of searching and fetching a much larger user record, if the fields on the profiles instead lived on the User object. > > * It solves the immediate problem ... > > As I see it, the immediate problem is that developers want to > be able to modify the base requirements of auth.User. There > may well be people who want to completely change contrib.auth, > but for the moment, the 90% case can be solved by modifying > max_length or setting unique=True on the email field, and/or > removing the username field. The rest of auth.User is fine, at least for now. I would disagree with this. The immediate problem from my POV is that a user who takes the latest release of django, installs the stock auth app has an email field which cannot hold valid email addresses, and a username field that cannot hold email addresses. It's unclear that your proposal changes this at all. One issue that you have not mentioned at all is schema changes with pluggable user models. If your average user is going to specify what fields his User model has in it, what processes will be put in place to allow the user to move from their current auth_user table structure? What about fixing the stock model definition (which will still have an email field, I assume)? Since schema changes have not been mentioned, I'm inferring that this would not change, and the 'fixed' version of django, by default, would still disallow a wide range of valid email addresses. I'm not -1 on pluggable auth models, I just think it is orthogonal to the real issue. A 'fix' which doesn't allow longer email addresses by default in d.c.a is not a fix as far as I am concerned. Cheers Tom -- 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.
