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.
I'll have a look at how that can be integrated in my own DBD work
> 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.
true, but to be honest, in my past discussions with you about the
issue, you were very reluctant, or at least that was my perception, to
amend this for a *generic* DBD-geared solution.
I'm all pro for a centralized well-defined and documented usable debug
interface.
> 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
Not entirely. I can easily understand if a debugging end-user has no
idea on what part of the DBD is actually used in his/her failing code,
and just slowly raises the level till the problem gets clear. If the
debug was written concisely, the message will hint toward a combination
of `area' and `level' to use next time. I'm hoping we'll get both
> 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.
Yes
> Having said all that, I can see some value in having a separate driver
> trace level. I suggest a few of the "middle 16 bits" are given over to
IMHO 4 bits will do (0..15). If that is correct, I'll also change the
levels to leave the basic levels 1 and 2 alone.
To be backward compatible, there should also be a flag that tells me to
ignore the DBI level if DBD level has been set (even to 0).
Currently the drivers will use the DBI level as shotgun method (as you
call it), but what if the end-user is interested in DBI-only messages,
and selects "3,0" specifically asking DBI-only at level 3, but keep
silent about DBD.
> that purpose. The "user interface" for setting the value could be as
> simple as setting a negative trace level. For example:
>
> $h->trace("1,-2"); # DBI trace level 1, DBD trace level 2
Why the minus?
As the sep char has never been documented before, this is the time to
give it intuitive meaning.
Simplest suggestion could be to separate DBI and DBD flags with a
semicolon, where empty parts will not change the current state
$h->trace (";select:3,commit:1");
$h->trace ("1;pgstart:1,pglogin:6");
$h->trace (1); # = $h->trace ("1;");
maybe even allow a hash.
$h->trace ({
DBI => { file => "dbi_dbg.out",
level => 3,
},
DBD => { file => \*DEBUG,
level => 4,
types => "pgstart, pglib",
},
});
but I might be wandering into lalaland here
> Tim.
>
> p.s. re the separator for the trace values... the code is currently
> for my $word (split /\s*[|&,]\s*/, $spec) { ... }
> (see parse_trace_flags() in DBI.pm) but there's nothing magical about
> those characters. To emphasize that, it should perhaps be changed to:
> /\s*[-\W]\s*/
> but that might limit any magic we may wish to add in future.
--
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/
