On Tue, May 29, 2012 at 7:35 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Wed, May 30, 2012 at 4:42 AM, Bill Freeman <ke1g...@gmail.com> wrote: >> I continue to struggle with occasional circular import problems >> (caused by a combination of haystack, filebrowser, and a model which >> both has a search_indexes.py and a model that has a filebrowser >> field). >> >> I had thought that I had patched the issue by importing haystack in my >> root urlconf (the problem doesn't happen under the development server >> because it "validates models" early, but the import order was >> different in production). But: 1, I kept having to add "import >> haystack" to my management commands; and 2, it still occasionally >> fails on restart (a timing hazard of some kind). >> >> It strikes me that one fix would be to defer haystack's scan of the >> INSTALLED_APPS until all the apps have been loaded. But when is that? >> I can ask django.db.models.loading.app_cache_ready(), but it will say >> False when haystack (or its models.py, which it has, despite not >> having any models) is being imported (since the list of apps being >> cached can't be finished until haystack.models import has finished). >> So when could I run it again? It would be nice to register for an >> "apps are loaded" signal, but I don't see on in the docs, and there is >> no evidence of sending one in django.db.models.loading.AppCache. >> >> Is there a right way to get something called after all the models have >> been imported? (Django 1.3) > > Unfortunately, there isn't. This is a long standing problem, and one > that the app-refactor was looking into; however, that effort hasn't > come to fruition. Django's startup sequence is an area where some work > is required. The closest thing to a "signal" you're going to get is to > hook into the URL configuration, in the same way the admin > registration process does -- but it looks like you've tried that and > haven't had any luck. > > One trick that I'm aware of that *might* work in your case is to force > the validation code to run in your production stack -- for example, as > a call in your WSGI container. From a functional perspective, this is > an expensive no-op. The validation won't ever return a different > result, which is why Django's WSGI handler doesn't call validate. > However, the process of validation *does* cause the startup sequence > to be a little more predictable, because the validation mechanism > imports *all* your app modules in your project in a predictable order. > If your problem is being caused by an unpredictable import order, > forcing a specific import order may work around your problem (or at > least make the side effects more predictable, and match the behaviour > of the development server). > > Yours > Russ Magee %-)
Thanks Russ. I guess that I could just try importing django.db.models in my wsgi file (in turn imports django.db.models.loading, which initializes the AppCache) as a validation equivalent? Bill -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
