On Tue, Mar 20, 2012 at 1:37 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > > 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).
(I'm not manually fixing up the line length in your emails any more, so sorry to others about the quoted line lengths) Yes, I'm aware of your stance on this. I was merely pointing out that with this scheme you will get 'pluggable' apps that insist on their own models, ie they are no longer pluggable. It's not a big deal. > 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. Right. So the conclusion to this is "Ship broken, allow people to fix it". > > 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. This argument again? If something is in the release notes for a new version, you only discover it 'by accident' if you do not read the release notes. How does this differ to enabling csrf protection by default? > >> 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. > In the other thread, I documented a procedure where by whether the stock User model was 'fixed' or not depended upon a setting. In the first release with the fix, a setting is included that allows the user to use corrected definitions for email and username, and a PendingDeprecationWarning is raised if you run without it. In the second release with the fix, a setting is included that allows the user to use uncorrected definitions for email and username, which raises a DeprecationWarning if you run with it. The release notes for each release discuss the schema changes required, and management commands introspect the database to check for consistency between settings and database. I see this solution as similar to USE_L10N, it fixes the email length issue and having emails as username, and it eventually gets Django to a shipping default that is not broken, whilst supporting users who cannot/do not wish to change. It is orthogonal to whether we have pluggable auth models to not - the setting can as easily control the definition of fields in a base User class as it can in the original d.c.a. My heart literally sank this morning reading this thread, rabid +1'ing of new features, but still not fixing the problem. The suggested new features are cool, but please, please, please consider a solution that fixes the problem, rather than just making it easier to work around. 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.
