|
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
|