On Mar 22, 2012 10:55 PM, "Russell Keith-Magee" <russ...@keith-magee.com> wrote: > * This solution still has the circular dependency, because any app with a ForeignKey(settings.USER_MODEL) needs to have a settings import in the models.py file
Hmmm. I asked a question about that today and was told that importing django.db.models already meant implicitly loading settings, and so importing settings in a models.py would be transparent. django.contrib.comments uses the same import, though admittedly circularly importing django.contrib.comments.models from a settings file is far less likely. > * It isn't a transparent migration for any third party app -- they need to be updated to use ForeignKey(settings.USER_MODEL), not ForeignKey(User). However, the failure modes will be interesting, because the auth_user table will still exist -- so apps will have a legal FK to a table that will be empty. This is true. The main difficulty is that separating auth.User from auth.Group and auth.Permission is difficult and so removing django.contrib.auth from INSTALLED_APPS is currently impossible if you want permissions for contrib.admin, even if you have no need for auth.User. There are ways around this particular problem, I think. For example, fail to resolve foreign keys to User unless it is the current USER_MODEL, or don't even define the model at all. Both of these solutions are sort of ugly, but they do make failure modes more aggressively fail fast. Definitely worth pointing out in the wiki as a limitation. Alex Ogier -- 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.
