Hi,
Is there a "clean" solution nowadays?
I am making an app that should run some specific code after the whole
project is loaded.
I was thinking about a thread started in the models.py file of my app that
will try X times to run the code, something like that:
success = False
attempts = 0
while not success and attempts < 10:
attempts += 1
try:
run() # raise Exception if it fails
success = True
except:
pass
if attempts == 10 and not success:
# log or do something
What do you think? Any ideas?
Thanks.
Michael
Le lundi 13 décembre 2010 20:01:30 UTC+1, Pakal a écrit :
>
> 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 <[email protected]> wrote:
> > Is this mod_python specific or does it also happen with mod_wsgi or
> > gunicorn?
> >
> > On Dec 13, 3:47 pm, Carl Meyer <[email protected]> wrote:
> >
> > > Hi,
> >
> > > On Dec 12, 4:40 pm, Pakal <[email protected]> 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 view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/XTvSa27MoaQJ.
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-developers?hl=en.
