Hello jerry, jerry wrote: > When is Environment not a singleton? > > Is it possible to be running with more than one Environment at a time, > and if so, why? > > The reason why I ask is that within trac/db/util.py, I would like to > log some messages, but it seems very difficult to get a handle on the > right log to use. The log is opened in trac/env.py (calling down to > trac/log.py/logger_factory) and associated with the path to the Trac > Environment. > > Down within trac/db/util.py/IterableCursor/execute for example, I > could easily get a handle to the right log if IterableCursors had > > a) some connection to the DatabaseManager > b) some other way of determining the path to the trac environment (?) > or > c) Environment was a singleton > > More on the database later as I think and inspect some more, my > question right now, for general information, is when is Environment > not a singleton and how and why would that be? >
Adding log support for the SQL queries seems to be the topic of the month... Why are my print statements not enough for debugging? ;-) So if someone wants to add log support, I'd suggest trying to have a look at trac.env.Environment.get_db_cnx(), which is the usual entry point to the DB manipulations. At that time, it should be possible to attach a logger (the env.log should do) to the db connection object. That logger could be in turn attached to the wrapped cursors created by the connection and finally used in execute(). -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" 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/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
