General wrote:
>
> First issue is _should_log_* properties. What for are they exist?
> Standard lib's logging module allows to fine-tune levels per-logger or
> per-handler. But with those strange props such simple code works not
> as it should:
>
> engine_logger = sqlalchemy.log.instance_logger(engine)
> engine_logger.setLevel(logging.INFO)
>
> If engine was created with echo=False there will be no logging output
> (of course I haven't forgot to set up the handler). But if I call
> instance_logger() again _after_ setting level to logger, output will
> appear because instance_logger will set _should_log_info=True to
> engine and only after that engine start to actually write INFO to log.
> I can not understand the meaning of _should_log_* props.
unfortunately the logging module included with Python adds significant
performance overhead even if no handlers are configured. We would like
to be able to have fine-grained logging available in our library, but at
the same time when the logging is disabled for significant latency to not
be added to the application. Take a look at the source of logging.debug()
- a logger with a few levels of hierarchy and no handlers configured will
have about three method calls of overhead. Multiply that by, for
example, a log statement for each row received by RowProxy, and a log
statement for each column/result processor in the ORM, and it adds up to
many dozens of method calls per row. The primary hindrance to speed in
Python is function calls - perhaps projects like Unladen Swallow will
improve this but for now, Python application profiling is almost a linear
function w.r.t number of method calls. So we can either remove all the
log.debug() statements we have and just not have the capability available,
or gate them within a conditional as we've done.
>
> Second question is about putting the query parameters to the log. Now
> there are two log records for each query - first for the query itself
> (with placeholders instead of actual data) and the second for the
> query params. It makes processing log records very difficult. I think
> code which logs queries should look like
>
> self.engine.logger.info(statement, {'parameters': parameters})
>
> instead of
>
> self.engine.logger.info(statement)
> self.engine.logger.info(repr(parameters))
>
this is fine and I may consider implementing this in 0.6. Though have
you tried DEBUG level sqlalchemy.engine ? the result set processing
necessarily needs to be implemented as distinct log lines, so you'd still
have the problem of associating many log lines with one record. there's
a connection proxy that can be used for more elaborate schemes.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
