On 20/03/2012, at 8:38 PM, Tom Evans wrote: > >> * 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.
Absolutely. That's why I've kept talking about the need for a strong interface contract, and the fact that contrib.admin is in a strong position to set a minimal User interface contract. > 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. Go back and read my posts -- I've repeatedly said that I prefer UserProfile as a pattern for *app specific* data. The only role that I see pluggable user models solving is the issue of username and email length/uniqueness, and/or the tracking of additional data required for the authentication process. Anything else app specific should be kept in a UserProfile (or UserProfiles, or some other model related 1-1 with User). A side effect of pluggable user models is that it would allow people to put their profile data on their User model. However, as you point out, that has all sorts of complications, and requires the User object to become a monolith. I wouldn't recommend this approach, but as this thread has revealed, many people prefer this approach for performance or aesthetic reasons. The upside is that pluggable user models allows for this approach if people want it. However, that doesn't mean that the Django docs should encourage it. >> * 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. My proposal for this would be to treat the migration process the same as we've done for any other feature that we've added to Django -- make it an opt-in change with a documented migration path. For example, when we introduced localization, we set the default to USE_L10N = False, and made the default behaviors unchanged from the older unlocalized behavior. However, if you opted in to USE_L10N = True, you got all the nice new localization features, and possibly a couple of migration headaches. However, because it was an explicit opt-in, you're on the lookout for things that might have changed or broken. Similarly, I would argue that we if we include this change, we have to ship a concrete User model that is *unchanged* from it's current definition. We then have three options: 1) Ship an updated User model (say, SimpleUser) with corrected email max_length (and any other changes that pop up). We document the process for opting in to using SimpleUser, including the ALTER TABLE statements that are required to modify any existing databases. 2) Ship a range of sample User models representing common User model patterns (e.g., using email as login, username but no email, etc) and provide the migration path for each. 3) Punt on the entire issue, document the limitations with the built in User model, and let the community manage User models; document what people need to do in order to switch, but leave migration as an open question that people providing new User models need to answer. Personally, I'd be in favor of option (3), mostly because what the last 6 years has taught us is that no matter what we pick as field names/sizes, *someone* will be unhappy. However, I won't get too bent out of shape if Django ends up shipping at least 1 new concrete User model -- at the very least, it's a good way to prove we can eat our own dogfood. If we introduce 1-N new User classes, we could also take the opportunity to make one of the new User models the default user if you deploy auth using an App definition, but User the default otherwise. This means that any new projects would get the new SimpleUser class, but existing projects would get the older User class. The key point here is that we're not forcing every Django user to discover by accident that they need to run an ALTER TABLE statement in order for their projects to keep working. The opt-in nature of the change is key. > 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. I don't see it at orthogonal at all. There is *no* way to address the email length problem without involving an ALTER TABLE statement somewhere. This migration can be either opt-in or mandatory. Opt-in changes have historically been preferred by Django as a project -- a position that I strongly support. If the process is opt-in, we need to have a way to perform that opt-in, and support both the old and new styles of email field. The only way I can see making this opt-in change orthogonal to having a pluggable User is if you're proposing a solution that *only* fixes the email length setting -- and while might be possible, it seems extraordinarily short sighted given all the other known problems and limitations with the auth User model. That means we need to have a way to plug in a new user model, and replace the old one. Yours, Russ Magee %-) -- 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.
