Re: promised trace flags change - a bit late

On Sun, Feb 06, 2011 at 01:17:15PM +0100, H.Merijn Brand wrote:
> > > 
> > > #   0xddlDDDrL (driver, driver-level, DBI, reserved, Level)
> > > 
> > > would be perfect in my world.
> > 
> > That's fine.
> > 
> > > 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.
> > 
> > Yeap.
> > 
> > > 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?
> > 
> > I think it makes sense.
> > 
> > Thanks.
> 
> I'll try to come up with a complete patch soon then

I've added these to DBIXS.h:

#define DBIc_TRACE_FLAGS_MASK   0xFF0FFF00  /* includes DBD flag bits for DBIc_TRACE */

#define DBDc_TRACE_LEVEL_MASK   0x00F00000
#define DBDc_TRACE_LEVEL_SHIFT  20
#define DBDc_TRACE_LEVEL(imp)         ( (DBIc_TRACE_SETTINGS(imp) & DBDc_TRACE_LEVEL_MASK) >> DBDc_TRACE_LEVEL_SHIFT )
#define DBDc_TRACE_LEVEL_set(imp, l)  ( DBIc_TRACE_SETTINGS(imp) |= (((l) << DBDc_TRACE_LEVEL_SHIFT) & DBDc_TRACE_LEVEL_MASK ))

Take a look at the DBIc_TRACE(imp, flags, flaglevel, level) macro.
I wonder if it's worth adding a corresponding DBDc_TRACE(...) macro
with an extra driver_level argument. I'm not sure it's worth it,
but then I'm not sure what semantics you're looking for.

Tim.