On Thu, 21 Aug 2008 20:38:28 -0000, "Greg Sabino Mullane" <[EMAIL PROTECTED]>
wrote:
> Despite all my nitpicking below, I think this is a good idea. :)
>
> > "DBD" All Driver flags
> > $h->trace ("DBD=7") could be an alternative to set the level
>
> Not sure I understand what "DBD=7" is supposed to mean. I presume
> that DBD is DBD only flags, but the number means some other level
> that only the driver should worry about?
Currently there is only "flags" supported, but most Drivers use a level
This was a last minute thought to specify "I want Driver-only debugging
at level 7". In hindsight, it is clear but ugly.
> > "1|4" Combination of a DBI debug level and a driver debug level
>
> This doesn't really make sense: most of the numbered ones run at a
> "greater than or equal to" (or <=) in the code. Also, DBI uses 4 as well,
> so it's not technically correct to call it a driver debug level.
> Only the higher, DBD-specific ones use specific bitmap matching, as
> far as I am aware. So any bitmap mashing only makes sense for things
> over 15, in general.
It's not meant as "or", but as "Driver level *before* the separator,
Driver-level *after* the separator. And currently only "1|foo" works.
> > Driver side $trace_settings can be stored in $ENV{DBD_TRACE}
>
> Not sure I see the utility of this one, why not just use DBI_TRACE?
> I guess it comes down to the same question as before, about passing
> the driver a specific number.
I write only portable scripts that deal with Oracle, Unify, and
Postgres (and some even MySQL). Having them tested in Oracle and now
testing them in Unify (or whatever sequence) makes me just want to see
what is happening on the Driver side when something goes wrong, and
setting DBD_TRACE to "4" would then just be a shortcut for setting
DBI_TRACE to "|4", which currently does not work. In my current git
repository, I already have DBD_TRACE working as expected.
> > All of the people I talked to agree that is is often useful to see
> > Driver-only tracing/debugging, as by now we do trust that DBI is Doing
> > The Right Thing (TM)
>
> Meaning that it is not outputting things in the DBD reserved tracing space.
You're wicked :) You probably didn't mean to, but DBI doesn't offer a
way to split DBI logging and Driver logging (yet)
As I read the docs, there is no specific Driver logging space. DBD::Pg
even offers a special setting flag in parse_flags to allow pgprefix to
visually make Driver space messages pop out of the logging stream
> > The problem with the current definition of the trace_flags, is that,
> > even though most drivers still work with a trace *level*, it only
> > supports trace *flags*. My implementation and suggestion of
> > $h->{dbd_verbose} is a nice workaround to start with, but it would be
> > easier to lift it to the trace method, so that Driver-only tracing is
> > more standardized
>
> Yep. It helps if we all think of the tracing as a single large number
> that can be bitmapped, and 1-15 are merely the ones without symbolic
> names. Because nobody wants to write 0x02000000 instead of 'pgstart'. :)
I like *BOTH*. Not that I have any flags implemented (yet), but having
a level AND a flag is good.
$dbh->trace ("2|pgstart,3");
meaning "I want DBI tracing at level 1, and pgstart logging at level 3
would be easy to explain in the docs.
$dbh->trace ("0|trigger,7|update,1|select,0|delete,4");
FWIW, re-reading all those docs made me well aware of a lot I didn't
know or realize, and as such was very worthwhile, even if this proposal
doesn't get new features implemented.
--
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/
