On Tue, Feb 01, 2011 at 10:58:14AM -0500, John Scoles wrote:
> On 01/02/2011 10:48 AM, Tim Bunce wrote:
> >On Mon, Jan 31, 2011 at 08:39:40PM +0000, Martin J. Evans wrote:
> >>I imagine most DBDs [if not all] that implement execute_array
> >[Just a reminder that drivers can opt to implement just
> >execute_for_fetch() and use the DBI's default execute_array() method,
> >which then calls execute_for_fetch().]
> >
> >>themselves) the rows affected will be -1 per execute (as the driver
> >>does not know affected rows) and so I'd expect $rows to be -1 and
> >>not 18. DBI gets away with this as it does an execute for each row
>
> The thing is OCI will know the end result of rows effected I just
> does not know the #rows for each statement.
>
> So on an update with say 4 tuples and 6 rows updates the tupels
> would look like this
>
> -1
> -1
> -1
> -1
> wile the list context one would get
> Tuples=4
> rows =6
I think we could factor into the spec the fact that some drivers can
return an overall row count but not per-tuple counts.
> My only concern is when it does error (no matter what the setting of
> AutoCommit) you always get unef;
Umm, yes. Returning undef (or an empty list) if there was any kind of
error causes useful information (the total row count) to be discarded.
This brings us back to the question of whether a failure of a single
tuple should cause execute_array() itself to return an error.
ODBC doesn't do that. It treats that situation as SUCCESS_WITH_INFO
and that does seem very reasonable.
> but I can live with that.
Perhaps we could default to the SUCCESS_WITH_INFO model and add an
attribute for people to use if they want tutple errors to cause
execute_array() itself to return an error.
We can debate the name later, but for now let's call it:
ArrayPromoteTupleError => 1
Tim.
