On 11/02/11 10:36, H.Merijn Brand wrote: > 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.
Well, I remember one of your original posts about dbd_verbose ages ago which didn't grab my attention at the time so I never contributed - we are all giving our time for free - sometimes things have to give. >> 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? Not sure. Doesn't parse_trace_flags get called at least? > 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. No, I guess not but isn't this simply because dbd_verbose is separate from DBI's trace levels and flags? If you allocate your 3 bits in DBI's trace flags (as I thought you were proposing and Tim agreed there was space for) then there is no need for dbd_verbose at all, you'll just use DBI's trace value and test against the DBD-level bits. Of course, you/we might have to add/change the macros a little to allow testing of those bits but that's ok isn't it? >>> dbd_verbose has never been *new* functionality, It was implemented as a >>> shortcut for already existing trace features. > That is where we disagree. Perhaps dbd_verbose in your DBDs is implemented that way but it does not look like that in some other DBDs (see my example above which suggests to me that [in that module] dbd_verbose is a global setting, not per handle, and requires an extra test). May be you didn't implement that way in your modules. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com