Re: promised trace flags change - a bit late

On 11/02/11 10:36, H.Merijn Brand wrote:
> On Fri, 11 Feb 2011 10:14:12 +0000, "Martin J. Evans"
> <[email protected]> wrote:
> 
>> On 11/02/11 09:05, H.Merijn Brand wrote:
>>> On Fri, 11 Feb 2011 08:42:21 +0000, "Martin J. Evans"
>>> <[email protected]> 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