On Wed, May 30, 2012 at 4:42 AM, Bill Freeman <[email protected]> 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 %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
