On reflection, I think the right fix for this (apart from fixing
DBD::mysql to support the ParamValues attribute if the latest one
doesn't) is to store the information in a private attribute and
use an overridden FETCH method to return that value.
Tim.
On Wed, Feb 23, 2005 at 09:23:42AM +0000, Gordan Bobic wrote:
> Hi,
>
> I'm trying to subclass DBI, but I'm having problems accesing DBI::st
> attributes. Say I want to override the DBI::st::execute() function to
> add the ParamValues attribute contents that is missing with using the
> MySQL driver.
>
> sub execute
> {
> my $Self = shift;
> my @Bound = @_;
>
> my %ParamValues;
> my $i;
>
> unless ($Self->{ParamValues})
> {
> for $i (0 .. $#Bound)
> {
> $ParamValues{$i} = $Bound[$i];
> print STDERR $Bound[$i] . "\n";
> }
>
> $Self->{ParamValues} = \%ParamValues;
> }
>
> return $Self -> SUPER::execute (@Bound);
> }
>
> This throws up a warning:
> Can't set MyDBISubclass::st=HASH(0x818591c)->{ParamValues}: unrecognised
> attribute or invalid value at .........
>
> The ParamValues doesn't get set.
>
> Doing something like this instead:
> $Self->{foo} = "bar";
> doesn't throw up a warning, but $Self->{foo} doesn't get set. Checking
> it immediately after setting returns nothing.
>
> Doing something like this:
> $Self->{private_foo_} = "bar";
> works, and the setting sticks, but then I cannot read it from outside
> the DBI::st subclass scope.
>
> How can I make this work?
>
> Many thanks.
>
> Gordan
