in reply to Re^2: Intercepting critical SQL inside DBI.pm
in thread Intercepting critical SQL inside DBI.pm

Writing a proxy object for DBI is not enough as you have to write proxies for the database handle and database statement as well.

A very simple approach is to enable the tracing in DBI, by calling DBI->trace('2|SQL|2', 'c:/Temp/DBI-Trace.txt') or setting $ENV{DBI_TRACE}='2|SQL|2'. This still has the drawback of writing to the filehandle. YOu could then use a tied filehandle maybe to analyze the lines written to it and use caller() repeatedly to identify the place where the statement was created from (by looking for the first non-DBD, non-DBI package in the calltree).

The DBI documentation claims that this is only implemented by some DBDs, but maybe MySQL/MariaDB have that feature...

Replies are listed 'Best First'.
Re^4: Intercepting critical SQL inside DBI.pm
by LanX (Saint) on Sep 16, 2022 at 16:18 UTC
    > as you have to write proxies for the database handle and database statement as well.

    I think you've missed this part

    > > and if another object is returned I'd wrap it into just another proxy.

    > YOu could then use a tied filehandle maybe to analyze the lines written to it and use caller() repeatedly to identify the place where the statement was created from

    ehm, yes ... probably you've missed this part

    > > DBI's trace documents a way to tie the filehandle and intercept messages. Probably I can also access the original callers.

    I was referring to DBI#Tracing-to-Layered-Filehandles

    But it depends on the actual implementation of DBI::trace, if I can really access the Perl callers.

    > A very simple approach is to enable the tracing in DBI,

    Personally I wouldn't call a tied filehandle a "very simple approach". YMMV...

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

[reply]

In Section Seekers of Perl Wisdom