On 05/02/2011 12:29, Tim Bunce 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
ok
and if so where do they go (in DBIXS.h?)
Just above DBIc_TRACE_MATCHES.
ok
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.
neither am I but on the DBI_TRACE=x|y|z line it is nicer for them to be
short.
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*.
ok
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.)
this is an area I am not that familiar with - bit out of my depth here
at the moment. Similar issue with handle attributes and method
attributes discussion - I understood what you said but am struggling to
implement it.
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).
Tim.
I'll leave that bit for Merijn as this seemed to be something he
wanted/needed.
I'll check in the changes I put forward in the next hour.
Martin
