On 20/01/11 09:55, Tim Bunce wrote: > On Wed, Jan 19, 2011 at 10:25:05PM +0000, Martin J. Evans wrote: >> On 19/01/2011 11:47, Tim Bunce wrote:
> Umm. I take that back. I suggest we change the spec from: > > When called in scalar context the execute_array() method returns the > number of tuples executed, or undef if an error occurred. > Like execute(), a successful execute_array() always returns true > regardless of the number of tuples executed, even if it's zero. > If there were any errors the ArrayTupleStatus array can be used to > discover which tuples failed and with what errors. I have always found the above wording confusing. I think I read 'tuple' as referring to a list of bind variables/values. Someone else might thing 'tuple' referred to a row in the database. > to either (new or changed text in capitals): > > a: When called in scalar context the execute_array() method returns the > number of tuples executed INCLUDING ANY TUPLES WHICH FAILED, > or undef if an error occurred THAT PREVENTED NORMAL OPERATION OF THE > METHOD. THE FAILURE OF SOME OR ALL TUPLES IS NOT REGARDED AS AN ERROR. > Like execute(), a successful execute_array() always returns true > regardless of the number of tuples executed, even if it's zero. > If there were any errors the ArrayTupleStatus array can be used to > discover which tuples failed and with what errors. > > or > > b: When called in scalar context the execute_array() method returns the > number of tuples executed IF ALL ARE SUCCESSFUL. IF ANY TUPLES > ENCOUNTER AN ERROR THEN execute_array() RETURNS UNDEF. > Like execute(), a successful execute_array() always returns true > regardless of the number of tuples executed, even if it's zero. > If there were any errors the ArrayTupleStatus array can be used to > discover which tuples failed and with what errors. > > I prefer (a) but (b) is how the DBI's default execute_array() and > execute_for_fetch() behave, which is obviously significant. I strongly prefer (b). I am sure that, if I am using RaiseError or HandleError, I want the exception route to be taken if *any* of the individual executes fail. >> The way I see it is that if some of the rows in the batch end up in >> the table and some don't I'd expect a warning. However, if 1 or more >> rows fail and no rows end up in the table I don't see any success so >> I'd expect an error. In my example code, 1 row fails but no rows end >> up successful so it is the latter. > > Shouldn't the number of rows "failing" and the number not ending up in > the database be the same? Anything else seems like a bug. Or are you > refering to a batch being aborted early? execute_array can be used for any non-SELECT DML statement. In general, a single successful execute can affect any number of rows, including zero. It is only in the case of a simple INSERT statement (with a VALUES clause) that there is a direct relationship between the number of successful executes and the number or rows affected. In some places in the current thread, the number of successful executes has been confused with the number of rows affected. -- Charles Jardine - Computing Service, University of Cambridge [email protected] Tel: +44 1223 334506, Fax: +44 1223 334679
