> > 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). >
Indeed I did. This was greatly appreciated. > 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. > You're right that my concern overlooks the case where reliance on the User goes beyond a mere ForeignKey, but I've found that in many cases usage is restricted to this simple interface. Maybe this is just a case of "sometimes life sucks", but I felt like I was wasting bits by forking a handful of packages for testing purposes only to change one line per project. I don't believe that there's a universal solution here and I'll respect that the current decision correctly chooses one pain over another. > 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. My concern here is that we're creating a situation where "if you try to use custom User models on day 1, don't plan to use third party packages that don't have proactive management". As above, this may be unavoidable, but it's unfortunate. > > 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. > I don't think the problem here is one of obviousness. I think there are unaddressed problems here that 'get it right before you sync' trivializes. Let's take django-activity-stream for example: https://github.com/justquick/django-activity-stream/blob/master/actstream/migrations/0001_initial.py#L14 In this migration, South has created an explicit reference to auth.User. The only two options I see are: 1) fork and manually patch the migrations to point to a custom user model or 2) abandon migrations (./manage.py syncdb --all && ./manage.py migrate fake) To be clear, the majority of this burden lies outside of Django (at least until we merge the migration branch). I tried to start the dialogue with the South community today, but I think we're well advised to make sure that community is aware of the issues this can create. As we've reviewed this, aside from the patch mentioned in my previous post, we have found no technical issues. The only concerns that remain from our team are focused on pragmatism and minimizing the burden on external developers. Best, - Ben -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/8yFCOK0TylEJ. 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.
