> Date: Fri, 31 Jan 2014 22:09:02 +0000
> From: tim.bu...@pobox.com
> To: byter...@hotmail.com
> CC: martin.ev...@easysoft.com; tim.bu...@pobox.com; hhferre...@gmail.com;
> boh...@ntlworld.com; dbi-users@perl.org
> Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
>
> 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: martin.ev...@easysoft.com
> > > To: tim.bu...@pobox.com; byter...@hotmail.com
> > > CC: hhferre...@gmail.com; boh...@ntlworld.com; dbi-users@perl.org
> > > 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
