On Fri, Jan 31, 2014 at 12:50:36PM -0500, John Scoles wrote:
> Well I did do some testing. The leak was very small (1k over 10 min run) but
> only when one does
> $shift->FETCH( 'ParamValues' ),
> in the child callback.
If it doesn't keep growing with more call then it's not a leak.
> Tim what would the impact of the above?? I know before 1.63 this
> $shift->{ParamValues'},
> gave you undef which is why the WTF comment was there.
Because the inner handle is a plain blessed hash ref, whereas the outer
handle is *tied* blessed hash ref.
There's no 'ParamValues' key in that hash, so you get an undef.
The ParamValues lookup is handled by the FETCH method call.
> Why if in the CB we had the outter handle would the FETCH give you the
> attributes of the Inner handle??
Calling $outer->{ParamValues} in a tied hash ref triggers a call to
$outer->FETCH('ParamValues') which then gets dispatched by the DBI to
$inner->FETCH('ParamValues') which does the work.
For more details see http://perldoc.perl.org/perltie.html
> Just a silly question?
No such thing :)
Tim.
> Cheers
>
>
>
> > Date: Fri, 31 Jan 2014 17:00:20 +0000
> > From: [email protected]
> > To: [email protected]; [email protected]
> > CC: [email protected]; [email protected]; [email protected]
> > Subject: Re: Issues with DBI Oracle Input Array Binds
> (ORA_VARCHAR2_TABLE)
> >
> > On 31/01/14 16:21, Tim Bunce wrote:
> > > On Fri, Jan 31, 2014 at 09:11:28AM -0500, John Scoles wrote:
> > >> A final note on this.
> > >>
> > >> Seems there was a very very long unknown bug in DBI which was only
> fix a few days ago wiht DB
> 1.6.31
> > >
> > > If you mean Callbacks getting an inner handle, that wasn't a bug as
> such.
> > > More like a design choice that proved non-optimal.
> > >
> > >>
> [1]http://blogs.perl.org/mt/mt.fcgi?__mode=view&_type=entry&id=5570&blog_id=2165
> > >
> > > That's
> http://blogs.perl.org/users/byterock/2014/01/callbacks-ate-my-brain.html
> > > I presume.
> > >
> > >> The end result of this bug was that when callbacks are used on the
> > >> statement handle some attributes will not be there so you
> > >> programmer who did this
> > >>
> > >> $sth->FETCH( 'ParamValues' ), # WTF? - returns a reference to an
> array of hashes
> > >>
> > >> was most likely complaing that the
> > >>
> > >> $sth->{ParamValues},
> > >>
> > >> should return a ref but was just returning undef.
> > >>
> > >> So he 'Kludged' the code to get the value directly with the FETCH
> which works
> > >
> > > I'm not sure what you're saying here John. Using
> $sth->FETCH('ParamValues')
> > > is perfectly reasonable. It was required before 1.631 and optional with
> > > 1.631+ now that $h->{ParamValues} works.
> > >
> > >> sort of, but it does bleed memory every so slighly.
> > >
> > > Are you sure? This is the first I've heard of such a leak.
> > >
> > > Tim.
> >
> > I've found no evidence of a memory leak with a simple test calling
> ParamValues a lot with some
> parameters. However, I'm not using ORA_VARCHAR2_TABLE. The code is:
> >
> > else if (kl==11 && strEQ(key, "ParamValues")) {
> > HV *pvhv = newHV();
> > if (imp_sth->all_params_hv) {
> > SV *sv;
> > char *key;
> > I32 keylen;
> > hv_iterinit(imp_sth->all_params_hv);
> > while ( (sv = hv_iternextsv(imp_sth->all_params_hv, &key, &keylen)) ) {
> > phs_t *phs = (phs_t*)(void*)SvPVX(sv); /* placeholder struct */
> > (void)hv_store(pvhv, key, keylen, newSVsv(phs->sv), 0);
> > }
> > }
> > retsv = newRV_noinc((SV*)pvhv);
> > cacheit = FALSE;
> >
> > }
> >
> > which looks sane to me right now. ORA_VARCHAR2_TABLE seems to do strange
> things with parameters I
> don't quite get right now.
> >
> > As I said previously to H�lder and John (some of the discussion was off
> dbi-users list presumably
> because it contained log data), although I accept taking the call to
> ParamValues out has on this
> occasion made the problem go away I don't understand why. I think there is
> more to this than it so far
> looks but without a way of reproducing it myself I won't be spending any
> more time on it. If it is
> reproducible in a standalone script I will happily look again.
> >
> > Martin
