I've never used these handlers yet, but from what I've browsed from django's code, it seems low level handlers have nothing to import models, so I guess the result would be the same. I guess I'll manually import all my INSTALLED_APPS models from within my settings.py or urls.py, for the moment.
But I still don't understand : where are we supposed to connect signals, then ? The signaling framework only makes sense if there is a clear startup phase in the server code, else it's just a nasty (and silent) trap for programmers, isn't it ? Regards, Pakal On 13 déc, 16:54, Harro <hvdkl...@gmail.com> wrote: > Is this mod_python specific or does it also happen with mod_wsgi or > gunicorn? > > On Dec 13, 3:47 pm, Carl Meyer <carl.j.me...@gmail.com> wrote: > > > Hi, > > > On Dec 12, 4:40 pm, Pakal <chambon.pas...@gmail.com> wrote: > > > > Why, then, isn't it specified that all models.py files should be > > > loaded by each starting worker ? That would solve the whole problem > > > and hidden errors around startup code like signals and startup checks. > > > This is a real issue for me as well; not necessarily that models.py > > isn't loaded at startup time, but the crucial difference in behavior > > between runserver and a live deployment in terms of when apps' models > > are imported, due to runserver performing model validation and thus > > importing all models immediately. I have more than once seen code that > > worked perfectly under runserver fail in subtle ways on real > > deployment for this reason. (In fact, the most popular Django search > > solution, haystack, is particularly susceptible to problems of this > > type, as it does some dynamic importing immediately when its models.py > > is imported). > > > So this is certainly on my radar screen as something I'd like to look > > at in the 1.4 timeframe. I'm not sure yet what a good solution would > > look like, and I'm not entirely convinced that importing all models.py > > at startup time is the right answer. In any case, the Google Summer of > > Code work by Arthur Koziel on app-classes will impact this area, and > > is scheduled for merge in the 1.4 cycle, so I'm kind of waiting for > > that to land before looking at this closely. > > > Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
