On Tuesday, March 20, 2012 at 10:08 AM, Tom Evans wrote:
> On Tue, Mar 20, 2012 at 1:37 PM, Russell Keith-Magee > <russ...@keith-magee.com (mailto: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 think the major difference is that CSRF protection for example always hard failed, so even though it was a change that required reading the release notes, if you didn't read those release notes your site would break obviously. However not all databases have this same behavior when trying to insert a string that is longer than the field allows. This means that for a certain subset of Django developers if they didn't read the releases note, or just missed that section of it that Django would not validate the length of the field to be 30, but would instead validate it to be much longer, Django would pass it to the database who for those users it would silently truncate the data. Above all else preventing silent data corruption is very very important. Arguments can be made about fixes that will cause hard fails (Exceptions) in every circumstance when the code hasn't been updated, but silent data corruption simply cannot be allowed to happen. > > > > > > > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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.
