Hey mate, Great stuff! A cursory glance shows there isn't anything to log debug output from url resolution.. something I think I need to add.. I'll busy a ticket for it :)
D On Sat, Sep 25, 2010 at 4:16 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > Hi all, > > I've just uploaded a first draft at a patch introducing logging into > Django [1]. I'm calling for feedback on this patch. > > [1] http://code.djangoproject.com/attachment/ticket/12012/t12012-alpha1.diff > > This patch is heavily drawn from the work that Vinay Sajip has done in > this area, but it also includes some significant changes to his most > recent patches. > > The patch introduces two settings: > > LOGGING_CONFIG - a callable that should be used to configure the > logging machinery > LOGGING - the configuration data to pass to the configuration function. > > By default, LOGGING_CONFIG points to logging.config.dictConfig, which > means that LOGGING should be a dict-style logging configuration (as > introduce by Python 2.7). A copy of dictConfig is included in utils > for backwards compatibility. However, by changing LOGGING_CONFIG, you > could use any configuration scheme you like. > > In addition, a new convention is introduced. If a Django app includes > a 'startup.py' as a sibling module to models.py, tests.py etc, then > this module will be loaded *exactly once* during the startup of the > app. It will be loaded *after* the settings have been initialized, but > *before* models.py has been imported. > > The patch includes the changes to the new project settings.py to show > what LOGGING would look like in practice. This logging configuration > puts everything to console, except for errors in the request process, > which are mailed to the admin. This means redirecting 500 errors to > something other than your email box is now a 1 line configuration > item. > > The patch also includes logging entries for everywhere in the code > where a 4XX or 5XX error is raised. 4XX's are raised as warnings; > 5XX's as errors. > > Lastly, there is a separate logger that logs, at the debug level, > every SQL statement that is executed. If you add a handler for > django.db.backends that catches the DEBUG level, you will get this > output. > > There are no docs because I'm waiting for the design to be finalized > before I start writing; there are no tests because this is something > that is a little difficult to test. > > At this point, I'm calling for feedback, particularly on the following: > > * logging config as the last stage of settings loading. Is this the > right place? Can anyone think of a better place? > > * The default logging configuration. Have I got the > propagate/override options right for sensible defaults (both in global > and new-project settings)? > > * The logging calls that have been introduced. Is this too much or > too little? I'd rather err on the side of caution here (we can always > add extra logging later), but I'd like suggestions on anything else > people think should be logged. Also, are they logged at the right > level (e.g., is a 404 a warning?). > > * The startup.py convention (and implementation). Is this necessary? > Does it address (or not address) any other prominent "on startup" use > cases? There's also a crossover here with Arthur's GSoC work; is the > startup code sufficiently important that we need it anyway, or can we > defer until the app refactor lands? > > So - have at it. I'm really excited by this; so let me know everywhere > I've messed up so that we can get this into trunk. > > Russ %-) > > -- > 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. > > -- 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.
