Hi David, I'm not sure I completely follow - what exactly are you looking to have logged? The pattern that was matched by the request?
As for raising a ticket - don't worry. About that at this point. For the moment, just keep he discussion on the ticket; if we decide that this is needed, we'll roll it into the commit for the main ticket. If you have a patch, just stick it on #12012. Yours, Russ Magee %-) On Saturday, September 25, 2010, David P. Novakovic <davidnovako...@gmail.com> wrote: > 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. > > -- 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.
