Re: Taking trace () to the next level ...

On Sun, 31 Aug 2008 23:56:43 +0100, Tim Bunce <[email protected]>
wrote:

> I'm back from vacation and have just read through this thread.
> I'm not sure I've followed it all, but here's a proposal from me
> that may refocus the discussion.
> 
> Current situation:
> 
> The internal DBIc_TRACE_SETTINGS(imp_xxh) value is a 32 bit int.
> The lowest 8 bits are used for TraceLevel 0..15.
> The middle 16 bits are reserved for DBI trace flags (effectively unused).
> The highest 8 bits are reserved for drivers.
> There's a DBIc_TRACE(imp, flags, flaglevel, level) macro documented as:
> 
>    DBIc_TRACE: true if flags match & DBI level>=flaglevel,
>    or if DBI level > level. This is the main trace testing macro to be
>    used by drivers.  (Drivers should define their own DBDtf_* macros for
>    the top 8 bits: 0xFF000000) Examples:
> 
>    DBIc_TRACE(imp,         0, 0, 4) = if level >= 4
>    DBIc_TRACE(imp, DBDtf_FOO, 2, 4) = if tracing DBDtf_FOO & level>=2 or level>=4
>    DBIc_TRACE(imp, DBDtf_FOO, 2, 0) = as above but never trace just due to level
> 
> though I think few drivers use this DBIc_TRACE macro.
> The DBI itself should use it but doesn't, simply due to lack of effort.
> 
> Desire:
> 
> As I understand it, the principle desire is for an additional 'trace level'
> dedicated for driver use.
> 
> I'd argue that the need for a separate trace level would be greatly
> reduced if the current DBI trace output could be more finely controlled.
> We should move away from using the 'shotgun' trace level to using named
> trace flags to specify exactly what we're interested in. Names can also
> be given to groups of flags so common sets of flags are easy to use.
> That'll require much greater use of the DBIc_TRACE macro.

Just inquired with some colleagues about where they would need (needed
in the past) debug output. (Just food for thought)

* Whitespace returned (diff between varchar and char, effect of
  ChopBlanks)
* Returned values for queries
* Statements actually passed to the database
* Failing Login
* Failing commit, rollback, cleanup

And in that brainstorm session, I though of something that would be
very useful: The option to stop outputting debug messages after the
first *error*, so the last debug lines on the screen/log_file show you
the error and not all the (failing) DESTROY and cleanup messages

-- 
H.Merijn Brand          Amsterdam Perl Mongers  http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/