On Fri, 11 Feb 2011 10:14:12 +0000, "Martin J. Evans"
<martin.ev...@easysoft.com> wrote:
> On 11/02/11 09:05, H.Merijn Brand wrote:
> > On Fri, 11 Feb 2011 08:42:21 +0000, "Martin J. Evans"
> > <martin.ev...@easysoft.com> wrote:
> >
> >> On 10/02/11 22:27, Greg Sabino Mullane wrote:
> >>>
> >>>> Trace level is no good to get DBD only tracing since level
> >>>> 1 and 2 is for DBI and anything after that is DBD.
> >>>
> >>> Yes, sorry about that, I was being lazy in my comingling of
> >>> trace levels and trace flags.
> >>>
> >>>> In addition, at the LPW speaking to Tim I mentioned I had
> >>>> implemented some trace flags in DBD::ODBC which were probably
> >>>> generic in nature and agreed to add them to DBI.
> >>>
> >>> +1
> >>>
> >>>> Whilst I was there I thought I could sort the trace DBD only
> >>>> issue out as well by adding a DBD trace flag.
> >>> ...
> >>>> $dbh->trace('DBD');
> >>> ...
> >>>> Which is now duplicated in DBI for all DBDs.
> >>>> I didn't realise you did that and although I can see
> >>>> why it means you've added a flag with an uppercase
> >>>> name which is reserved for DBI. I'm not sure you'll
> >>>> ever see DBD in your parse_trace_flags after 1.617
> >>>> so you'll need to do something similar to what I
> >>>> did (below) in addition to keeping what you already
> >>>> have (above) to cover older DBIs before 1.617.
> >>>
> >>> Okay, all that is good to know. So it should do
> >>> the same thing post 1.617 and the dbd::pg specific
> >>> code will never fire, right?
> >>>
> >>> ...
> >>
> >> yup, if you OR your DBD flag with DBDs DBD flag nothing will change
> >> for you. If someone uses pre 1.617 you will work as before and 1.617
> >> you will continue to work but your flag will be redundant. When you
> >> eventually raise your requirement to DBI 1.617 you can take your DBD
> >> flag out.
> >>
> >>>> The ENC flag is for encoding tracing.
> >>>
> >>> Thanks for the explanation there, as well as all the others I
> >>> did not quote here.
> >>>
> >>
> >> BTW, on your comment to Merijn re dbd_verbose reinventing the wheel.
> >> That is how I felt and I did not want to add another test to all my
> >> trace tests which is why I added the DBD flag instead. I'm not
> >> criticising anyone using dbd_verbose, I just did not want to do it
> >> that way and would rather work with what was already present in DBI.
> >
> > I don't see it as re-inventing the/a wheel. The DBD flag is for me like
> > an alias to dbd_verbose.
> >
> > $DBD_VERBOSE = 7
> >
> > is (or should be) equal to
> >
> > $DBI_TRACE = 7|DBD
>
> Thats fine but that is not how some people have implemented it Merijn.
Which is probably why this whole discussion started.
I'm feeling guilty of not having enough time atm to actually come up
with the suggested doc changed so DBD authors have a guide. IMHO that
was the main cause for all DBD debugging diverging.
> From DBD::Oracle's dbdimp.c:
>
> /* defined globally at the top of dbdimp.c */
> int dbd_verbose = 0; /* DBD only debugging*/
>
> /* double test */
> if (DBIS->debug >= 6 || dbd_verbose >= 6 )
Is there a trigger that makes a DBD function being called if DBI->trace
is invoked?
What I currently do is set dbd_verbose on connect, and use that.
Afterwards, you can alter it using $h->{dbd_vebose}. But what if
meanwhile DBI->trace changes the level with DBD flag set? How is the
DBD being informed? If I just use the dbd_verbose flag, that won't work.
> > dbd_verbose has never been *new* functionality, It was implemented as a
> > shortcut for already existing trace features.
--
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/
