Re: A signal, or equivalent, for when all apps are loaded?

On Tue, May 29, 2012 at 7:35 PM, Russell Keith-Magee
<russell@keith-magee.com> wrote:
> On Wed, May 30, 2012 at 4:42 AM, Bill Freeman <ke1g.nh@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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.