On Sep 18, 3:49 pm, "Michael Bayer" <[email protected]> wrote: > Vinay Sajip wrote: > > hmmm OK I think what he may be referring to is that we have this flag > called "echo" which works like this: > > engine = create_engine(url, echo=True) > > what "echo" does is a "shortcut" to setting up logging and enabling INFO > logging for the logger named "sqlalchemy.engine". In order to ensure > output, it does a basicConfig() to standard out. > > What happens though, particularly when people use Pylons or similar, is > that they have a logging configuration in their conf file, which already > sets up handlers for logging. then they'd like to use the "echo" flag for > debugging, but it ends up setting up a second handler, so in the case of > already logging to stdout you get double log messages. > > It would be nice if there were some APIish way we could check that > handlers have already been configured, so that the "echo" flag wouldn't do > a second handler configuration.
If you are literally calling basicConfig, that checks for handlers added to the root logger (as it's intended to configure the root logger for casual/novice usage, though of course anyone can use it). If the root logger already has loggers configured, then it doesn't do anything. If you're using basicConfig(), then it's probably just an ordering problem - your code gets called first, configures the root logger, then Pylons or other framework adds another handler explicitly. This can perhaps be handled by documentation, as it's (IMO) mainly an interaction between SQLA and the other framework. I'll take a peek at SQLA code sometime soon and make suggestions if I think any changes are needed, if that's OK. > > the "echo" issue is not really a big deal. the other issue we have is one > I'm not sure much can be done about. We have logging calls which we would > like to make within extremely performance critical sections, like when > fetching results. However if you look at our source code we jump through > hoops to avoid an unnecessary method call, like: > > if self._should_log_debug: > self.log_debug(...) > > otherwise the log_debug() would result in about three method calls per row > even when logging is disabled. A bad side effect of this is that in many > cases _should_log_debug is determined when an engine or session is first > created (based on logging.isDebugEnabled() etc.) - so an application has > to take care to set up their logging config before the rest of their > SQLAlchemy objects are generated. > Okay, let me think about that for a bit, and look at your source to see exactly what those methods do. > Those are pretty much the only two things we have, thanks for the interest ! > So - Armin's statement "SQLAlchemy for example does an incredible dance to get separate loggers for temporary database connections." doesn't ring any bells? Also - do you have any performance numbers or even rough metrics as to the overhead from logging in your tight loops? Regards, Vinay Sajip --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
