On Fri, 22 Aug 2008 18:31:08 -0000, "Greg Sabino Mullane"
<[EMAIL PROTECTED]> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> > It's not meant as "or", but as "Driver level *before* the separator,
> > Driver-level *after* the separator. And currently only "1|foo" works.
>
> ITYM DBI before and driver after? I can see how that might work.
Indeed, and currently it works weird. It *lloks* like OR, but the docs
allow both '|' and ',', but I cannot explain this:
$ perl -MDBI -wle'for(1,0,"1|0","0|4","1|4","4|1"){DBI->trace($_);print
DBI->trace}'
DBI 1.607-nothread default trace level set to 0x0/1 (pid 27689) at -e line 1
1
0
0
DBI 1.607-nothread default trace level set to 0x0/4 (pid 27689) at -e line 1
4
4
DBI 1.607-nothread default trace level set to 0x0/1 (pid 27689) at -e line 1
1
See, it always takes the last group of digits, and does not OR at all
> >> 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)
>
> Sure there is: the top 8 bits are DBD, everything else is DBI. Unless you mean
> splitting up the 1-15 items as far as where each is generated from (DBI vs
> DBD),
> which does not seem horribly useful.
I didn't mean the *flags*, I meant the output stream
> > 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
>
> Not sure what you mean by "space" here. If we really wanted to enforce
> a strict split between all flags based where they were generated from,
> DBI vs. DBD, regardless of their level, I could see that being able to
> pipe one or the other to a specific named file might be useful.
>
> >> 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.
>
> Saying a "level AND a flag" is a little confusing. The flag is merely a
> shortcut for a specific level,
Not in my perception. There are regions or sections that one might like
to debug (connect, cursors, select, delete, update, insert, trigger,
prepare, execute, cleanup, destroy, disconnect, error handling ...) and
to each of those regions I can imagine a level of verbosity. The
definition/selection of a region is imho completely decoupled from a
level. Currently we have only one level, but I have little trouble to
imagine several
> which is basically just a very large number.
> I'm not sure what 'pgstart logging at level 3' means either. 'pgstart'
> is strictly boolean: if it is set, then DBD::Pg outputs trace information
> about each function start, irregardless of what the level is. It's all
> part of one number anyway. pgstart is 0x02000000, and the current trace
> value is Bitwise Anded to this. Snippets from Pg.h:
>
> #define TFLAGS (DBIS->debug & DBIc_TRACE_FLAGS_MASK)
> #define FLAGS_START 0x02000000
> #define TFSTART (TFLAGS & FLAGS_START)
>
> > $dbh->trace ("0|trigger,7|update,1|select,0|delete,4");
>
> Interesting. So you are proposing expanding SQL into finer-grained items.
That was a brain-fart, but yes, that is the basic idea
> We'll certainly need a larger trace number at that rate, but that's fine,
> as I for one would certainly like to have more bits available to the drivers
> so we can have more than the current 8 private ones.
>
> On re-reading the above, I think your intent really is determining not so
> much what level something is, but where it comes from (DBI vs DBD), something
> the current trace system is not really set up to support. So ideally, you'd
> want something like this (very psuedo-code):
>
> $dbh->dbi_trace(0);
> $dbh->dbd_trace(2);
\o/ This means I was clear enough. Exactly!
So far, John and I implemented this as $dbh->{dbd_verbose}, which still
uses the default logging stream.
> Named private DBD flags would presumably work when passed to either one,
> although
> an argument could be made that the dbi_trace one would simply ignore any in
> the
> top 8 bits, and perhaps that dbd_trace would ignore anything in the lower bit.
>
> I'm still not convinced that showing a level 3 from DBD but not from DBI is
> a good idea. If DBI were not already outputting certain things, DBD::Pg would.
> But because that debug output is already "covered", DBD::Pg does not bother
> to output, in the expectation that level 3 is level 3. That assumption would
> need to change across all drivers.
If we reach a standard that covers most of the above, I'm more than
willing to change my debug levels to match it
> Okay, enough rambling and speculation for now... :)
--
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/
