On Mon, Apr 5, 2010 at 8:35 AM, Torsten Bronger < bron...@physik.rwth-aachen.de> wrote:
> Hallöchen! > > Thierry Chich writes: > > > Is manage.py sqlall working ? > > Yes. > > I think I understood the problem now. It's a complicated case of a > cyclic import. If I have > > INSTALLED_APPS = (A, B) > > then "manage.py syncdb" tries to generate the tables for A and > imports A.models. The problem occurs if A.models imports B.models > on top-level (e.g. for sub-classing models of B). Then, Django > imports B.models and executes the code in B.models. This contains > admin.site.register calls. If DEBUG=True, those calls try to > validate all existing models, which means that A.models is imported > again, although B.models hasn't been executed fully yet. Therefore, > B.models' __dict__ is not yet populated. Thus, the import of > B.models in A.models -- which is triggered for the second time by > now -- fails. > > Whew. > > Adding > > if "syncdb" in sys.argv: > DEBUG = TEMPLATE_DEBUG = False > > in settings.py is an acceptable workaround for me. Should I file a > Django bug report? > I don't think so. There's already a ticket open ( http://code.djangoproject.com/ticket/11696) for import errors not being raised properly by management commands, which I think is the Django bug you encountered here. If I'm understanding your description properly, a better fix for your code is to remove admin.site.register calls from models.py. Independent of this other problem you ran into, admin registration calls in models.py files are not recommended, since there is no guarantee when running in a production environment that all your models.py files will be loaded "early". Putting admin.site.register calls in models.py files tends to lead to confusing behavior of the admin, where you bring up an admin page and it does not list all the apps/models you expect because the associated models.py file, containing the admin registration calls, has not yet had any reason to be loaded. (runserver explicitly validates models, meaning your models files are always loaded early when running under the dev server...this does not happen in a typical production setup) This is why the recommended approach is to put admin registrations in admin.py files, and include a call to admin.autodiscover() in urls.py. This ensures that all admin registrations are completed before the URL for the first incoming request is resolved to a view function. It sounds like following this advice would also have the side-effect in your case of avoiding this circular import problem. Karen -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
