On Jan 15, 1:47 pm, Simon Willison <si...@simonwillison.net> wrote: > My biggest hangup with the logging implementation was figuring out > exactly when the logging configuration code should actually run. The > problem is that Django's startup execution order is poorly defined - > stuff relating to settings is lazily evaluated the first time it's > needed, and there's no real documented place to put code that needs to > be executed once (the fact so many registration things end up being > called from urls.py is a good indicator that this is a problem). > > This has put me off using signal handlers in my own code in the past, > and it also came up with the logging work. > > I think Django needs a defined and documented execution order on > startup. I'm not entirely clear why we've avoided this in the past - > I've readhttp://www.b-list.org/weblog/2007/nov/05/server-startup/but > it hasn't convinced me that a defined startup order for things like > registration patterns, signal handlers, logging configuration is a bad > thing. > > Personally, I'd like to see this happen as part of the instantiation > of a single Django "site object" which handles all requests to the > server. We almost do this at the moment - if you look at the code > inhttp://code.djangoproject.com/browser/django/trunk/django/core/handlers/ > each handler basically instantiates an object once which then has its > get_response() method called for every incoming request. Unfortunately > the time at which this object is instantiated seems to be pretty ad- > hoc - how and when it happens depends on if you're running under WSGI, > mod_python or the development server. > > Defining Django's execution order is a pretty big job, but it would be > a great thing to achieve for 1.3. The obvious thing to tie it to would > be INSTALLED_APPS - it could be as simple as having an API promise > that the first thing Django does when it "starts" is to run through > each application in INSTALLED_APPS looking for and importing an > autoload.py module. I imagine we'll find that the time at which models > are registered is critical (what if autoload.py wants to use a model > that hasn't been loaded in to the AppCache yet?) and may need to do > more than one pass through INSTALLED_APPS. Plenty of details to figure > out.
You make many valid points, Simon, but at least as far as the narrower goal of setting up logging is concerned, I had a look at this back in October and came up with a candidate solution which worked for me. I'd be grateful if you took a look at it and highlight any drawbacks of the approach. The one point we know must be reached before any request handling takes place is the reading of settings.py, so I based my approach on that. From what I can see, the approach I've outlined is not just suitable for setting up logging but also doing model-related stuff such as listening for e.g. class_prepared signals etc. from the app loading machinery. Here's a link to the October post: http://groups.google.com/group/django-developers/msg/90b81d9f927d0bf0 Regards, Vinay Sajip
-- 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.
