On Sat, 5 Feb 2011 12:29:09 +0000, Tim Bunce <[email protected]>
wrote:
> On Fri, Feb 04, 2011 at 08:00:13PM +0000, Martin J. Evans wrote:
> > Tim,
> >
> > At the LPW I think I promised to add connection and encoding trace
> > flags to DBI which add to the already existing SQL flag. I never got
> > around to it and Merijn reminded me today on #dbi. The change is
> > trivial and once implemented I will replace DBD::ODBC trace flags
> > for connection and encoding with the standard DBI ones. There only
> > remains 2 small issues wrt to this which need confirming:
> >
> > 1. DBI currently says
> > return 0x00000100 if $name eq 'SQL';
> >
> > and as there is no macro for 0x00000100 I have the following in
> > DBD::ODBC:
> >
> > /* Can't find a constant in DBI for SQL tracing but it is 256 */
> > #define SQL_TRACE_FLAG 0x100
> >
> > and then code like this:
> >
> > if (DBIc_TRACE(imp_dbh, SQL_TRACE_FLAG, 0, 3)) {
> > TRACE1(imp_dbh, " SQLExecDirect %s\n", SvPV_nolen(statement));
> > }
> >
> > Should there be macros for DBI's trace flags
>
> Yes. I'd suggest
>
> #define DBIf_TRACE_SQL 0x00000100
>
> > and if so where do they go (in DBIXS.h?)
>
> Just above DBIc_TRACE_MATCHES.
>
> > 2. I propose adding connection and encoding flags to DBI - so far
> > they've kept pretty short:
> >
> > ALL
> > SQL
> >
> > so I've replicated this with:
> >
> > sub parse_trace_flag {
> > my ($h, $name) = @_;
> > # 0xddDDDDrL (driver, DBI, reserved, Level)
> > return 0x00000100 if $name eq 'SQL';
> > return 0x00000200 if $name eq 'CON';
> > return 0x00000400 if $name eq 'ENC';
> > return;
> > }
> >
> > and:
> >
> > Currently the DBI only defines four trace flags:
> >
> > ALL - turn on all DBI and driver flags (not recommended)
> > SQL - trace SQL statements executed
> > (not yet implemented in DBI but implemented in some DBDs)
> > CON - trace connection process
> > (not yet implemented in DBI but implemented in some DBDs)
> > ENC - trace encoding (unicode translations etc)
> > (not yet implemented in DBI but implemented in some DBDs)
> >
> > is this ok?
>
> I'm not a huge fan of short names in general, but in this case I think
> it's reasonable.
>
> > and 2 supplementals:
> >
> > 3. I could look into implementing some/all those flags in DBI but it
> > seems these areas are pretty much covered with trace levels right
> > now
>
> I think it's worth adding CON. It would enable connect and disconnect to
> be traced *with no other output*.
>
> > and in any case, I cannot find prepare in DBI (for SQL tracing)
> > anyway.
>
> The trace flag checking would need to be applied in XS_DBI_dispatch
> and controlled by the 'Internal Method Attributes' (dbi_ima_st).
>
> I'm thinking it would work along these lines:
>
> When a method with the CON trace flag is called and the current
> trace setting on the handle has the CON trace flag set, then the trace
> level will be set to min(trace_level,2) for the duration of the call.
>
> Sound ok?
>
> (I've partly implemented that but not tested it yet.)
>
> > 4. Lastly (and not wanting to get in Merijn's way who agreed to look
> > at it) but at the same workshop you discussed dbd_verbose (or
> > whatever some DBDs have added support for) with Merijn and we think
> > you said there is space in the trace settings for DBD trace
> > settings. Apparently some DBDs only want DBD tracing and not DBI
> > tracing so trace level is no good as it always includes DBI tracing.
> > I think you were talking about reserving some space for DBDs only -
> > perhaps you could remind us - the idea being settings (or a setting)
> > which outputs DBD tracing but not DBI tracing.
>
> As you note above, the current trace settings are encoded into an int:
>
> # 0xddDDDDrL (driver, DBI, reserved, Level)
>
> Where L is the DBI trace level (0-16) and the rest are bit flags.
> The 4 reserved bits could be used as a driver trace level (0-16).
# 0xddlDDDrL (driver, driver-level, DBI, reserved, Level)
would be perfect in my world.
Why I started the whole debug discussion so long ago, was that I by now
trust the way DBI does handle what it has to handle, and 95% of the
time I run into trouble, I just want to see what the driver (DBD) is
doing in the back.
So far I didn't get all the authors into a straight line. We all had
our own vision in what was most useful to debug our own DBD without
looking at how other DBD's did their debugging, and I must say I am
just as guilty.
Now back to that "need", I invented $DBD_VERBOSE => $dbh->{dbd_verbose}
to skip all the DBI messages (as said, they only caused noise to what I
wanted to see).
back to 0xddlDDDrL
l than is "level" to DBD, what "L" is to DBI
How many bits in DDDD do you think will ever be used? If we now use 2
or 3, wouldn't it be better to change to
# 0xddlDDDrL ?
Which would mean that we stay 100% backward compatible (as the first D
of DDDD was only reserved but never used.
With this scheme, it is extremely easy for all drivers to update their
docs to match DBI. Those drivers that used a level will just have to
use the 'l', those that used flags will (still) have to use the dd.
We could then document the use and support of DBD_VERBOSE to
automatically translate to the ddl part. If a DBD already supported
$DBD_VERBOSE instead of "ddl", it will work just as it did, if the DBD
updates to the new scheme (requiring DBI-1.xxx that supports it), then
the "upgrade" is automatic and doesn't change a thing from the user
point of view.
Am I being messy? Or does this all make sense?
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
