On Tue, Jul 04, 2006 at 02:18:33PM +0100, Martin J. Evans wrote:
>
> Thanks for the explanation. You have not however convinced me this behavior is
> right. If RaiseError caused a die on error and someone wanted to ignore errors
> they could just do what they always do - turn RaiseError off and do the
> checking themselves.
>
> What I was really after was whether not dying on an error in execute_array
> when RaiseError was enabled was by design or a an oversight.
An oversight. Though the oversight is actually in execute_for_fetch()
which execute_array() array calls to do the real work.
> It makes a
> difference to me since I read the DBI docs and saw nothing which said
> RaiseError does not work with execute_array, then discovered it didn't,
> worked around this in my DBIx extension but would like to document why I
> have this workaround.
Try this (untested):
--- DBI.pm (revision 6604)
+++ DBI.pm (working copy)
@@ -1931,7 +1931,10 @@
push @$tuple_status, [ $err, $errstr_cache{$err} ||=
$sth->errstr, $sth->state ];
}
}
- return ($err_count) ? undef : scalar(@$tuple_status)||"0E0";
+ my $tuples = @$tuple_status;
+ return $sth->set_err(1, "executing $tuple_status generated $err_count
errors")
+ if $err_count;
+ return scalar(@$tuple_status) || "0E0";
}
Tim.
