On 25.09.2010, at 08:16, Russell Keith-Magee 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?
To expand on this a bit, the refactored app cache from Arthur's GSoC branch introduces a dedicated place for app related information to live in, the app class. With the dotted app path given to a new setting called APP_CLASSES it will be picked up during startup by the app cache, creating app instances. Given the fact that the current implementation of the app cache does quite a few hoops to make it possible to implicitely import the models modules by iterating over INSTALLED_APPS, I'd like to propose to rather move the logging initialization to the app class initialization, instead of introducing another place of implicite importing -- to prevent having ambiguous locations for app specific code execution. Only problem is that the inclusion of the refactored app cache into trunk wasn't planned for 1.3, which is why I suggest we recommend using the management.py for optional logging initialization in 1.3 and add app-level logging hooks in 1.4 when the new app cache lands. Jannis -- 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.
