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 [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.
