Tim Bunce wrote:
> On Wed, Jan 20, 2010 at 03:24:23PM +0000, Martin Evans wrote:
>>>> but I don't see any call to connect when clone is called.
>>> You don't see a call to DBI->connect, but there is a call to
>>> $drh->connect via the closure.
>>>
>>>> I presume there is something I need to do - any ideas?
>>> The closure calles the connected() method ad that's a good method to
>>> override to (re)setup any private stuff you need.
>
>> Tim,
>>
>> Thank you for the pointers.
>
> I'm glad you could interpret it despite the typos :)
>
>> I had all DBIx::Log4perl setup in the
>> connect method (strangely I don't recollect reading about the connected
>> method) and after moving it all to the connected method and deleting my
>> failing attempt at clone override this now seems to work except:
>>
>> o when I pass DBIx::Log4perl attributes in the connection e.g.,
>> connect('dbi:Oracle:xxx','user', 'pass', {DBIx_l4p_logmask => 1})
>>
>> I get warnings from the connect closure like this:
>>
>> Can't set DBIx::Log4perl::db=HASH(0x87116c0)->{DBIx_l4p_logmask}:
>> unrecognised attribute name or invalid value
>>
>> Previously I didn't get these as I parsed my attributes out in my
>> connect method then deleted them before DBI saw them but now I need them
>> to get down to the connected method but I don't want those warnings and
>> the code checks before calling connected:
>> [...]
>> and I cannot capture them in connect as this does not work for clone (as
>> my connect never gets called if you clone).
>
> It seems that the current clone method doesn't play well with DBI
> subclasses.
Doesn't seem to although can be made to work.
> I've never been very happy with the behaviour of the clone() method
> (which is why it has "likely to change" in the docs) but I've not had a
> clear idea of what to do with it.
I saw the "likely to change" but unfortunately the problem is others
have ignored it and there are examples all over the place (quite a
number on perlmonks) of forking where they use clone.
> Part of the problem in this case is that you're using uppercase
> attribute names. If you used lowercase then things might 'just work'.
Argh - I had read the "Driver or database engine specific
(non-portable)" attributes are in lower case and can contain underscores
back in the distant past but must have forgotten that when it came to
writing DBIx::Log4perl.
Making that change does in deed make those warnings go away and I am
happy to make that change since it was written down and DBI spec.
> Otherwise you probably need to override clone() to remove your
> attributes (perhaps stashing them in a 'private_l4p_tmp_attr'
> attribute), call the SUPER::clone and then handle your attributes.
> Either after SUPER::clone returns or in connected().
That is sort of where I started - overriding clone and I had all sorts
of other issues so I'd rather not go there again.
If I moved to lowercase attribute names and moved all the setup code I
used to have in the overriden connect to connected would that be
compatible with the DBI spec as far as you are concerned and how you had
envisioned it to be done.
>> o "Can't locate auto/DBIx/Log4perl/st/DELETE.al"
>>
>> I feel this is something I've done wrong but I cannot find it yet. My
>> connect method is trying to call $dbh->func('dbms_output_enable') in
>> DBD::Oracle (as it always has done) but it is failing in my execute
>> attempting to undefine HandleError:
>
> Does DBIx::Log4perl::st subclass DBI::st? It needs to.
>
> Tim.
>
>
Yes:
st.pm:
use strict;
use warnings;
use DBI;
use Log::Log4perl;
package DBIx::Log4perl::st;
@DBIx::Log4perl::st::ISA = qw(DBI::st DBIx::Log4perl);
use DBIx::Log4perl::Constants qw (:masks $LogMask);
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
