Hi Fraser,
Thanks for sharing this app with us. After a quick read through, I've
some
points on the initialising code in middleware.py:
#==========================================
handler = ThreadBufferedHandler()
handler.setLevel(logging.NOTSET)
handler.setFormatter(logging.Formatter())
logging.root.setLevel(logging.NOTSET)
logging.root.addHandler(handler)
#==========================================
(a) Setting NOTSET on the root logger will cause absolutely everything
to
go through the logging system - this could be unnecessary overhead as
well
as being too much information.
(b) You don't need to set NOTSET on the handler - that's the default
setting.
(c) You don't need to set a do-nothing formatter on the handler, as
you are
not using the formatting capability anyway.
(d) It's probably better to put logging configuration in settings.py;
this is
something people will want to tweak without touching your app. The
middleware code still adds value in terms of adding the formatted
HTML to
the end of the response. So, I would move this code to settings.py.
Also, you could consider using thread locals to hold the list of
records, as
this usage seems what they were designed for.
> Jeremy, what database backend are you using? On MySQL I don't see any
> SQL getting logged. I guess registering the handler to the root logger
I think Jeremy is talking about the potential for a lot of logging
output.
AFAIK, Django does not use logging in the core code - this would need
to be added. Recently, when I was doing a legacy migration into
Django, I kept
hitting constraint errors which were hard to find amongst the
thousands of
records being inserted. Hence, I had to add some logging to my working
copy to
troubleshoot these issues.
> must mean it gets all the log information from the other loggers too.
> It's on my to-do list to add the ability to filter by logger so that
> you can opt-in or -out of the messages from libraries, etc.
This kind of functionality is already built into the logging system.
For
example, a user could set up in settings.py:
import logging
root = logging.root
root.setLevel(logging.ERROR) # root setting inherited by all
root.addHandler(ThreadBufferedHandler())
logging.getLogger("mysite.app1").setLevel(logging.INFO) # override
logging.getLogger("mysite.app2").setLevel(logging.DEBUG) # debugging
this now
You can set levels for loggers used by libraries from settings.py,
too.
Supposing that SQL was logged in django/db/backends/utils.py to a
logger
named "django.db.backends.util". Then by default with the above setup,
no SQL
logging below ERROR happens, because the logger inherits its settings
from its
ancestor (i.e. root, in this case). Setting the logging level in
settings.py,
logging.getLogger("django.db.backends.util").setLevel(logging.DEBUG)
will turn on SQL logging, with no other changes needed. To turn the
verbosity
down again, simply comment the line out or set some other level on the
logger.
Because loggers operate in a hierarchy, if the logger names used by a
module
are the same as the module name, then even if logging code is added to
Django
core code, you could easily turn up or down the verbosity of selected
chunks
of the framework, e.g.
logging.getLogger("django.contrib").setLevel(logging.DEBUG)
or
logging.getLogger("django.contrib.auth").setLevel(logging.DEBUG)
to affect all of the django contrib modules, or just the auth modules.
Regards,
Vinay Sajip
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
