On Sep 17, 11:53 am, Ivan Sagalaev <man...@softwaremaniacs.org> wrote:
> Talking about predictable and standard way I want to be sure that we
> don't break existing logging.
>
> I.e. we at Yandex now have many reusable Django apps that don't setup
> loggers themselves but just log things into named loggers and expect
> them to be setup by a project that uses them.
That's normal. The pattern I use is:
In each module which needs to use logging, instantiate a module-global
logger using
logger = logging.getLogger(__name__)
and log to it in the module's code. The configuration happens in
settings.py.
> What I gather from your proposal is that you want the same model ("an
> app logs, a project setups") plus a nice declarative syntax in
> settings.py instead of boring creation of handlers, formatters and
> loggers. Right?
>
Actually you don't need much in settings.py, and Django doesn't need
to grow any code of its own to "wrap" logging. You can either
configure logging programmatically (for which I use basicConfig, in
simple setups) or using a configuration file (ConfigParser-based,
fully documented in Python docs) for more complex setups.
> > - We could replace (or complement) django.connection.queries with a
> > log of executed SQL. This would make the answer to the common question
> > "how do I see what SQL is being executed" much more obvious.
>
Yes, I do this with a patched CursorDebugWrapper. You can direct the
SQL to a separate file which contains only the SQL events and not
other logging events.
>
> We had this problem with standard logging. Then we switched to a
> RotatingFileHandler which wasn't very good however because its behavior
> is simplistic and is not controllable by admins with an interface that
> they know, namely logrotate. Setting up logrotate also wasn't without
> problems. When it rotates a file it should let an app know about it and
> it uses SIG_HUP for that. However this instantly terminates Django's
> flup-based FastCGI server which we use.
>
> Now we've settled on a WatchedFileHandler ported from Python 2.6 logging
> module. It watches for file descriptor change and doesn't require
> SIG_HUP to pick up a new file. May be we should port it to Django and
> use it as a default handler for logging to file system.
Why "port it to Django"? Do you mean, copy it into Django? I'm not
sure it should be the default - not everybody uses logrotate. I'd
leave this sort of decision for code in settings.py.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
