Re: Tricky problem: database tables are not created
Hallöchen! Karen Tracey writes: > [...] > > 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. Thank you, this solved the problem! Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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.
Re: Tricky problem: database tables are not created
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.
Re: Tricky problem: database tables are not created
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? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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.
Re: Tricky problem: database tables are not created
Is manage.py sqlall working ? Le 5 avr. 2010 à 14:03, Torsten Bronger aachen.de> a écrit : Hallöchen! Torsten Bronger writes: [...] But it gets even more strange: The models module of "chantal_ipv" imports models from "samples". I think this is the problem. If I comment out all calls to admin.site.register in the models of "samples", it works! WTF? I tracked the problem down to the file django/db/models/loading.py. "import_module" in the method load_app fails. Apparently it tries to load chantal_ipv.models which in turn loads samples.models which in turn calls admin.site.register, which starts the loop again. The whole thing belongs to model validation which doesn't take place if "DEBUG=False". By the way, how can I get proper tracebacks from "manage.py --sync"? "--traceback" doesn't do it. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 . -- 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.
Re: Tricky problem: database tables are not created
Hallöchen! Torsten Bronger writes: > [...] > > But it gets even more strange: The models module of "chantal_ipv" > imports models from "samples". I think this is the problem. If I > comment out all calls to admin.site.register in the models of > "samples", it works! WTF? I tracked the problem down to the file django/db/models/loading.py. "import_module" in the method load_app fails. Apparently it tries to load chantal_ipv.models which in turn loads samples.models which in turn calls admin.site.register, which starts the loop again. The whole thing belongs to model validation which doesn't take place if "DEBUG=False". By the way, how can I get proper tracebacks from "manage.py --sync"? "--traceback" doesn't do it. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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.
Tricky problem: database tables are not created
Hallöchen! I have INSTALLED_APPS = ( "django.contrib.auth", "django.contrib.contenttypes", "django.contrib.sessions", "django.contrib.admin", "django.contrib.markup", "chantal_ipv", "chantal_common", "staticfiles", "samples", ) However, syncdb ignores chantal_ipv. It doesn't even load chantal_ipv.models (at least, syntax errors don't show up). If I put chantal_ipv last in the list, it works (but I need it in the middle). The strange thing is that it works nicely on my production system. The Django revision is the same, it's just Python 2.6.5 instead of Python 2.6.4. But I cannot see anything in Python release notes which changed the way modules are imported. But it gets even more strange: The models module of "chantal_ipv" imports models from "samples". I think this is the problem. If I comment out all calls to admin.site.register in the models of "samples", it works! WTF? Has anybody an idea what's going on or how I can debug this further? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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.
