On Tue, Sep 05, 2006 at 09:13:04PM +0100, Martin J. Evans wrote:
> On Tue, 2006-09-05 at 20:36 +0100, Tim Bunce wrote:
> > 
> > @@ -1921,10 +1921,12 @@
> >         # start with empty status array
> >         ($tuple_status) ? @$tuple_status = () : $tuple_status = [];
> >  
> > +       my $rc_total = 0;
> >         my ($err_count, %errstr_cache);
> >         while ( my $tuple = &$fetch_tuple_sub() ) {
> >             if ( my $rc = $sth->execute(@$tuple) ) {
> >                 push @$tuple_status, $rc;
> > +               $rc_total += $rc;
> >             }
> >             else {
> >                 $err_count++;
> > @@ -1935,7 +1937,9 @@
> >          my $tuples = @$tuple_status;
> >          return $sth->set_err(1, "executing $tuples generated $err_count 
> > errors")
> >              if $err_count;
> > -       return scalar(@$tuple_status) || "0E0";
> > +       $tuples ||= "0E0";
> > +       return $tuples unless wantarray;
> > +       return ($tuples, $rc_total);
> >      }
> Yes, obvious, I was thinking from the app side (where ArrayTupleStatus
> would be required) instead of the DBI side which already has the result
> from execute. 
>  
> > Could you check it, add any polish needed, plus some docs (noting
> > Ronald's clarification) and, ideally, some tests?
> 
> Will do although how does this affect the DBDs that implement
> execute_array themselves? e.g. Oracle.

The docs just need to say that in list context some drivers may supply
and extra return value giving the sum of the rows affected for each tuple.

> Given Xho's comment it would also seem wise to add to the docs that
> ArrayTupleStatus may not contain the actual affected rows for some
> drivers e.g. Oracle.

True. (Though I didn't see Xho's comment)

> Also, given xho's comments that the bulk method in DBD::Oracle does not
> know the affected rows (and hence returns -1 affected rows)

That's a great shame if it's true. Seems odd though.

> the actual change will be of no use to me (I will have to drop using
> execute_array since I need to be sure the number of rows I intend to
> insert or update are updated).

Perhaps bulk insert to a temp table then run a stored procedure to
perform the required operation and return the rows affected.

> In my experience, running an update which does not affect
> any rows when the intention was to update a row is usually a serious
> error so it is a shame execute_array won't provide this but if OCI can't
> do it, it can't.

I agree. Perhaps there is a way but I don't have time to research the
OCI docs. It does seem like an odd ommision.

> I will amend my rt.cpan.org bug report as the main issue was returning
> -1 in rows affected.
> 
> > If you don't have commit access to the repository yet then send me your
> > auth.perl.org (or bitcard.org) username and I'll give you access so you
> > can commit it yourself.
> 
> I was wondering how long I could hold out after your request for
> assistance on DBI 1 - it would seem I managed less than a week ;-)

:)

> My username is mjevans.

You should have write access shortly.

Welcome! And, thanks!

Tim.

Reply via email to