From: shane <sh...@lo...> - 2003-10-20 11:07:40
|
On Saturday 18 October 2003 07:18, Cliff wrote: > Recently, I've been working on a more formal way of debugging > the SQL associated with Slash sites that I happen to run. This > came from me being sick and tired of having to navigate error > logs after adding a "print $sql" to Slash::DB::Utility::prepare and > trying to find the SPECIFIC SQL statement I wanted in the > logs. > > Sooo... I hacked Slash::Apache and Slash::DB::Utility > to provide a new Apache configuration directive for Slash: > > SlashDebugSQL "<space separated list of packages or scripts>" > > So. If I was looking for SQL associated for Search and for admin.pl, > I'd add the following to my Apache conf: > > SlashDebugSQL "Slash::Search admin.pl" > > And ONLY the SQL from those files would be sent to the error > logs. nice. > Note, that this is NOT designed for use on production servers > (please!), this is for testing machines only, and uses a custom > version of DB/Utility.pm to do its magic. I have yet to figure out > how to roll this into Slash so that it is as unnoticeable as possible > in a production environment. It's one of the reasons I haven't > made a formal patch yet. If anyone has any ideas as to how I > can alias Slash::DB::Utility::_prepare to one of two different subs > depending on a boolean conditional, please let me know. I have > ideas, I'm just not sure how well they work in practice and am still > working at it. > > So would others be interested in me continuing work on formalizing > this? Yes >Or would care for their own personal version of my changes? Yes :) Please send me a patch. There's only one thing I think I'd change - Make it dump to it's own logfile, something like /{installdir}/sites/sitename/logs/sql.log. But that's debateable since I've not seen what you've done, obviously. Shane |