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/