On Wed, Sep 19, 2012 at 9:13 AM, Ben Slavin <benjamin.sla...@gmail.com> wrote: > Hi Russ, > > First, let me apologize for being a bit late to the party on this. If > there's been prior discussion of any of the points below kindly tell me to > get stuffed and so shall I do.
You asked for it… :-) > Our team has been working with the t3011 branch today. > > We ran into some trouble running tests locally. The tests were in our own > project (not django), but BaseDatabaseIntrospection.sequence_list() was > listing sequences for all models, and not taking into account that some > might be swappable. Josh Ourisman threw together a patch to fix this. Russ: > You should have seen a pull request, but the diff is available at > https://github.com/joshourisman/django/commit/ef46bbb5520499ebcda2e074446d2c4a055dd6e8 I've seen the pull request. It looks good on first inspection; lI'll try and find some time tonight to merge it in. > We've run into quite a few issues with third party packages that have > foreign keys to auth.User. Fixing this may be outside the scope of Django > proper, but it will require work with the community. To enable our testing, > we've had to fork quite a few apps. Ok - this is how the migration path *should* work (at least, this is how it was planned to work): If your project is using the default User, nothing changes. Third party apps have an explicit foreign key to User, and they continue to work. If your project specifies a custom user, you should get validation warnings saying that there are foreign keys to a swapped model (and indicate which foreign keys are affected). This does means that there is a "1.5 compatible" barrier to entry for apps. However, the barrier is clearly marked and validated, it only matters if you want to use the 1.5-specific "custom User" feature, and the migration path should be fairly simple. The update verges on being fixable with a regex, but not quite, since you really do need to engage a brain in the process to make sure you haven't got any implied User interface contracts. Yes, this does mean we need to work with the community. The 1.5 release notes do mention this, but would warrant making a bit more noise about this when we do the release -- possibly a "If you read nothing else, read this" section of the release notes. > An especially large problem has been with South. Existing migrations will > explicitly refer to auth.User. That is to say: a fresh installation on the > initial `./manage.py migrate` will behave incorrectly because foreign keys > will be pointing to an incorrect model. I inquired over on #django-south and > didn't get any response on any possible plans to handle the new use cases > introduced by the t3011 changes. Not a core problem, but something we should > work with the community on to ensure a smooth path. Agreed - migrations are going to be a problem. That's why the docs currently say "get this right before you sync". I'm open to suggestions on how to make this more prominent/obvious. > Lastly, I haven't seen a path to easily allow third-party apps to gracefully > support both The Old Way and The New Way (1.4 and 1.5). It feels a bit > wrong, but should we be considering the addition of get_user_model and > settings.AUTH_USER_MODEL to 1.4.x that's hardcoded to contrib.auth.User so > third-party apps can rely on the presence of these mechanisms? This is a good suggestion, and one that has some precedent with other features we've introduced in the past. > All of this aside, this is great work. This has been an itch I've longed to > scratch for quite some time, and this work does it more completely and more > correctly than my efforts in django-samaritan. Cheers to you, Russ, and to > everyone who's been part of forming this solution over the last six years! You're most welcome. Like you've said, my contribution is really only the last little part -- this has been a work in various forms of progress for a long time, and I've certainly benefited from the experiences of others. Russ %-) -- 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.
