On Tue, Sep 28, 2010 at 7:43 PM, Luke Plant <l.plant...@cantab.net> wrote:
> On Sat, 2010-09-25 at 14:16 +0800, Russell Keith-Magee wrote:
>
>> * The default logging configuration. Have I got the
>> propagate/override options right for sensible defaults (both in global
>> and new-project settings)?
>
> I just noticed that the project template settings and the global
> settings are different. The global settings use a null handler for debug
> logs, while the project template config would send them to stderr. I
> can see the value of having debug calls appear on the console while
> running the development server, but most people will take the template
> settings.py as a good starting point for deployment. Since we have
> already defined DEBUG in the template settings.py, how about changing
> the project template to have this:
>
> LOGGING = {
> 'version': 1,
> 'disable_existing_loggers': False,
> 'handlers': {
> 'null': {
> 'level':'DEBUG',
> 'class':'django.utils.log.NullHandler',
> },
> 'console':{
> 'level':'DEBUG',
> 'class':'logging.StreamHandler',
> },
> 'mail_admins': {
> 'level': 'ERROR',
> 'class': 'django.utils.log.AdminEmailHandler'
> }
> },
> 'loggers': {
> 'django': {
> 'handlers':[DEBUG and 'console' or 'null'],
> 'propagate': True,
> 'level':'INFO',
> },
> 'django.request':{
> 'handlers': ['mail_admins'],
> 'level': 'ERROR',
> 'propagate': True,
> },
> }
> }
>
> That will give a settings.py that is sensible for both development and
> deployment.
Hrm. I'm not sure I agree.
The reason for having different settings between global_settings and
template settings is support for old projects. If you've got a legacy
project, you won't have a LOGGING setting, so the logging needs to be
identical to what is produced right now -- which is to say, emails for
server errors, but everything else to the bitbucket.
I can see the value in adding the null handler as part of the project
template, but I'm not sure about the "DEBUG and 'console' or 'null'"
logic. To my mind, 'just write to the console' is a reasonable
default, regardless of whether you're in testing or production; in
practice, if you're in production, you're going to need to tweak
propagation, level, and probably push the handlers to something
better, too. Making the default as simple as possible (i.e., just say
console) makes more sense to me than trying to presuppose how a log
will be used in production.
That said, it's a bit of a moot point: there isn't anything written to
the 'django' logger at this point in time. In practice, the value of
the setting is pretty much irrelevant for the moment. 'null' is as
good as any, as long as it's clear that this is what is happening.
For completeness, we should probably add a logger entry for
'django.db.backends' that pushes everything to null.
So - here's a revised proposal, which can be shared between both
global and project template settings:
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'null': {
'level':'DEBUG',
'class':'django.utils.log.NullHandler',
},
'console':{
'level':'DEBUG',
'class':'logging.StreamHandler',
},
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler'
}
},
'loggers': {
'django': {
'handlers':['null'],
'propagate': True,
'level':'INFO',
},
'django.db.backends':{
'handlers': [],
'level': 'INFO',
'propagate': True,
},
'django.request':{
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': True,
},
}
}
Yours,
Russ Magee %-)
--
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.
