Re: Taking trace () to the next level ...
John Scoles <[email protected]>
| Newsgroups | gmane.comp.lang.perl.modules.dbi.sybase.devel |
|---|---|
| Organization | The Pythian Group |
| Message-ID | <[email protected]> |
H.Merijn Brand wrote: > On Tue, 02 Sep 2008 19:03:26 +0100, "Martin J. Evans" > <[email protected]> wrote: > > >> H.Merijn Brand wrote: >> >>> On Tue, 2 Sep 2008 11:15:20 +0100, Tim Bunce <[email protected]> >>> wrote: >>> >>> >>>> On Mon, Sep 01, 2008 at 05:01:40PM -0700, Jonathan Leffler wrote: >>>> >>>>> On Mon, Sep 1, 2008 at 3:30 PM, Tim Bunce <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>>> On Mon, Sep 01, 2008 at 01:31:57PM +0200, H.Merijn Brand wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Sun, 31 Aug 2008 23:56:43 +0100, Tim Bunce >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>>> Having said all that, I can see some value in having a >>>>>>>> separate driver trace level. I suggest a few of the "middle >>>>>>>> 16 bits" are given over to >>>>>>>> >>>>>>> IMHO 4 bits will do (0..15). If that is correct, I'll also >>>>>>> change the levels to leave the basic levels 1 and 2 alone. >>>>>>> >>>>>> Actually I'd rather squeeze the levels concept down to 0..7 for >>>>>> both DBI and DBD levels in order to make two more flag bits >>>>>> available and to encourage greater use of flags. >>>>>> >>>>> FWIW, DBD::Informix uses trace levels from about 3 to 9 (leaving >>>>> 1 and 2 for DBI output only). >>>>> >>>>> Whether that matters is another issue, but 4 bits would be >>>>> preferred (though three is not the end of the world). Unless you >>>>> have a use for those 2 bits at the back of your mind... >>>>> >>>> Although it looks like the trace level range is being reduced, it's >>>> effectively being increased. It's just that instead of a single >>>> range you'd now have two. >>>> >>>> The current highest levels of driver internals tracing would then >>>> be controlled via the DBD trace level. Something like this: >>>> >>>> $h->trace("2,-6"); # DBI trace level 2, DBD trace level 6 >>>> >>>> That gives you more control because you can enable higher levels of >>>> DBD tracing without being swamped by higher levels of DBI tracing. >>>> >>>> >>>> >>>> >>> Sounds ok >>> >>> >>>> You could/should also define some trace flags for specific topics >>>> to give finer control. Something like this: >>>> >>>> $h->trace("2,-4,ix_charset"); >>>> >>> We will need some extra macro's to get the dbd level and the flags >>> Any suggestions? >>> >>> >> I like what I'm reading in this thread. As others have said I would find >> it beneficial to be able to trace DBD::ODBC without getting DBI tracing. >> In an attempt to get DBD::ODBC tracing without DBI tracing I moved some >> tracing to trace flags. Unfortunately, this had a rather unfortunate >> side effect. I created an odbcconnection trace flag and put all my >> connection tracing under that. The problem is the only way to set the >> flag before connecting :-( is: >> > > That is why I also support $ENV{DBD_TRACE}, in analogy with > $ENV{DBI_TRACE}. > > I would have to agree with $ENV{DBD_TRACE} It would be very useful for me while debugging connections as well. >> use DBD::ODBC; >> DBI->trace(DBD::ODBC->parse_trace_flags('odbcconnection|odbcunicode'); >> >> The current trace macros allow tracing if a flag is set, tracing if a >> flag is set and the trace level is at least N, and tracing if the level >> is at least N but NOT tracing if a flag is set OR the level is at least >> N. I'd find the latter greatly beneficial for the above reason. >> > >