-----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.
>> 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.
> 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, 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.
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);
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.
Okay, enough rambling and speculation for now... :)
- --
Greg Sabino Mullane [EMAIL PROTECTED]
End Point Corporation
PGP Key: 0x14964AC8 200808221421
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkivBdcACgkQvJuQZxSWSsgkFgCeKZPb+eWscM/v9hDSi1dvOaut
dLIAoJqBAbg34SGk5J6YhHfMV27fmNjh
=9VE1
-----END PGP SIGNATURE-----
