Re: promised trace flags change - a bit late

On 04/02/2011 20:00, 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 and if so where do they 
> go (in DBIXS.h?)
>
> 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?
>
> 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 
> and in any case, I cannot find prepare in DBI (for SQL tracing) anyway.
>
> 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.
>
I've looked in to what ora_verbose/dbd_verbose does and it seems it 
simply duplicates the trace level in a separate setting and requires 
checking along with each check on DBI's trace level. I don't much like 
this and think it might be better to just add a DBI "DBD" trace flag so 
any DBD can do:

if (DBIc_TRACE(imp_dbh, DBD_TRACE_FLAG, 0, 3)) {

I'll add that to the list above unless I get any negative feedback.

Martin