RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
From: byter...@hotmail.com
To: tim.bu...@pobox.com
CC: martin.ev...@easysoft.com; hhferre...@gmail.com; dbi-users@perl.org
Subject: RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
Date: Fri, 31 Jan 2014 18:04:44 -0500
Opp hit send too fast
> Date: Fri, 31 Jan 2014 22:09:02 +
> 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.
>
With of course the older DBI <1.63,
I did not see a leak with 1.63 no matter how long I let it run
> 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.
>
In pre 1.63 in the callback it would be like this;
Calling $inner->{ParamValues} = undef;
calling $inner->FETCH('ParamValues') which does the work.
OK
>
$inner->{ParamValues}
> 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 +
> > > 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 o
RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
> Date: Fri, 31 Jan 2014 22:09:02 +
> 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 +
> > > 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
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 +
>> 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
RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
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.
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.
Why if in the CB we had the outter handle would the FETCH give you the
attributes of the Inner handle??
Just a silly question?
Cheers
> Date: Fri, 31 Jan 2014 17:00:20 +
> 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
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
Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
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.
>The latest version of DBI with the
>
>$sth->{ParamValues},
>
>Should solve all you problems
>
>As a bonus I have another topic for me blog
>
>Cheers
>John
>
>
>
>
>Date: Wed, 29 Jan 2014 14:21:28 +
>Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
>From: hhferre...@gmail.com
>To: boh...@ntlworld.com
>CC: byter...@hotmail.com
>
>You are right Martin.. Shame on me :(
>At the time you suggested that we did not know about the callbacks, sorry
> for that, our fault :(�
>Now that we know the root of the problem I'm sure we will be able to
> implement a solution.�
>Thanks a lot for your time, tips and patience :)
>I would be more than pleased to offer you a ginginha, porto /portuguese
> wine accompanied by a special
>local cheese or a "portuguese egg tart" case you pass by here!
>Best Regards,
>H�lder Hugo Ferreira
>
>On Wed, Jan 29, 2014 at 12:04 PM, Martin J. Evans <[2]boh...@ntlworld.com>
> wrote:
>
> On 29/01/14 11:02, hhferreira wrote:
>
>Hey Guys!
>
>John, your tip about the callbacks revealed to be very accurate!!
>
> I seem to remember saying a long time back in this thread:
>
> "Have you got some sort of execute callback? I ask because of the
> following in the trace:
>
> � � {{ execute callback CODE(0xb832be8) being invoked
>
> and it is only present before the error."
>
> hmmm.
> �
>
>We managed to isolate the issue into this statement:
>
>� debug( "Executing SQL on OptiDb database:",
>� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
> � �sql_executer � � � � =>
>sprintf( "%s line %s (%s)", (caller(0))[1,2],
> $sth->{private_keep_alive_seconds} ? 'active: keeping
>connection open' : 'maintenance' ),
>� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
> � �statement � � � � � �=>
>$sth->{Statement},
>*params � � � � � � � => $sth->FETCH( 'ParamValues' ), # WTF? -
> returns a reference to an array of
>hashes*
>� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
> � �connected_since � � �=>
>sprintf( "%s (%.3f seconds)",
>� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
> � � � � � � � � � � � � � � �
>� � �strftime( "%H:%M:%S", localtime(
> $dbh->{private_connected_at_timestamp}[0] ) ),
>� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
> � � � � � � � � � � � � � � �
>� � �tv_interval( $dbh->{private_connected_at_timestamp} ),
>� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
> � � � � � � � � � � � � � � �
>� � �),
>� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
> � �keep_alive_timestamp =>
>$dbh->{private_keep_alive_until_timestamp}
>� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
> � � � � � � � � � � � � � � �
>�? sprintf( "%s (%s seconds to live)",
>� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
> � � � � � � � � � � � � � � �
>� � � � � � �strftime( "%H:%M:%S", localtime(
> $dbh->{private_keep_alive_until_timestamp} ) ),
>� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
> � � � � � � � � � � � � � � �
>� � � � � � �( $dbh->{private_keep_alive_until_timestamp} - time() ),
>� � � � � � � � � � � � � � � � � � � � �
RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
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
http://blogs.perl.org/mt/mt.fcgi?__mode=view&_type=entry&id=5570&blog_id=2165
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
sort of, but it does bleed memory every so slighly.
The latest version of DBI with the
$sth->{ParamValues},
Should solve all you problems
As a bonus I have another topic for me blog
Cheers
John
Date: Wed, 29 Jan 2014 14:21:28 +
Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
From: hhferre...@gmail.com
To: boh...@ntlworld.com
CC: byter...@hotmail.com
You are right Martin.. Shame on me :(
At the time you suggested that we did not know about the callbacks, sorry for
that, our fault :(á
Now that we know the root of the problem I'm sure we will be able to implement
a solution.á
Thanks a lot for your time, tips and patience :)
I would be more than pleased to offer you a ginginha, porto /portuguese wine
accompanied by a special local cheese or a "portuguese egg tart" case you pass
by here!
Best Regards,
HÚlder Hugo Ferreira
On Wed, Jan 29, 2014 at 12:04 PM, Martin J. Evans wrote:
On 29/01/14 11:02, hhferreira wrote:
Hey Guys!
John, your tip about the callbacks revealed to be very accurate!!
I seem to remember saying a long time back in this thread:
"Have you got some sort of execute callback? I ask because of the following in
the trace:
á á {{ execute callback CODE(0xb832be8) being invoked
and it is only present before the error."
hmmm.
á
We managed to isolate the issue into this statement:
á debug( "Executing SQL on OptiDb database:",
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á
ásql_executer á á á á => sprintf( "%s line %s (%s)", (caller(0))[1,2],
$sth->{private_keep_alive_seconds} ? 'active: keeping connection open' :
'maintenance' ),
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á
ástatement á á á á á á=> $sth->{Statement},
*params á á á á á á á => $sth->FETCH( 'ParamValues' ), # WTF? - returns a
reference to an array of hashes*
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á
áconnected_since á á á=> sprintf( "%s (%.3f seconds)",
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á
á á á á á á á á á á á á ástrftime( "%H:%M:%S", localtime(
$dbh->{private_connected_at_timestamp}[0] ) ),
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á
á á á á á á á á á á á á átv_interval( $dbh->{private_connected_at_timestamp} ),
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á
á á á á á á á á á á á á á),
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á
ákeep_alive_timestamp => $dbh->{private_keep_alive_until_timestamp}
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á
á á á á á á á á á á á? sprintf( "%s (%s seconds to live)",
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á
á á á á á á á á á á á á á á á á ástrftime( "%H:%M:%S", localtime(
$dbh->{private_keep_alive_until_timestamp} ) ),
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á
á á á á á á á á á á á á á á á á á( $dbh->{private_keep_alive_until_timestamp} -
time() ),
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á
á á á á á á á á á á á á á á á á á)
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á
á á á á á á á á á á á: '',
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á);
I guess the former developer added that suggestive comment for a reason :)
Now we don't really now how to resolve this issue here because this debug
function cannot simply be removed as it logs into a file very important data
required in case we need to track down business issues. I suppose the problem
here is that the ora_varchar2_table parameters are themselves arrays and when
they reach a certain size it crashes.
Any tip to replace this $sth->FETCH('ParamValues') statement into a workable
one? Maybe reduce the number of items in each of the inner arrays to 100 or so
could be a solution... We will try to investigate in this direction. If you
have some sort of magic that could share we would be very appreciated :)
P.S. If you ever come to Portugal let us know and we will be very pleased to go
out with you for a beer or two!
Best Regards,
HÚlder Hugo Ferreira
All the FETCH doe
