You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Christopher Lamey <cl...@localmatters.com> on 2006/06/01 21:02:15 UTC

Re: public int executeBatch()

Hello,

I use executeBatch quite a bit and would not want to see it break
backwards compatibility in a minor version release.

FWIW, BatchUpdateException is thrown if there's an exception during a
batch update and has enough info for me to figure out what broke when.
The getUpdateCounts() method on that exception tells me how many
statements were executed successfully and any that didn't have a value
of Statement.EXECUTE_FAILED.  BatchUpdateException uses the SQLException
getNextException() scheme, which should really change to the 1.4
exception chaining mechanism.  But it doesn't, and if followed usually
leads to a specific sql exception that contains the sql and values in
question.  I suppose this is dependent on the driver implementation...I
happen to currently use postgres, which fills out the messages very
nicely.  The SQLState and ErrorCode in the exception can be useful as
well.

Cheers,
Chris

On Wed, 2006-05-31 at 10:53 -0400, rs wrote:
> > I think the JIRA patch is a good starting point towards working on a solution 
> > to this.  rs - if you have further suggestions please add them to the JIRA 
> > issue (for example, what do you mean by "return code"?  1/0? SQLCode?  
> > SQLState?). 
> 
> My suggestion is that instead of returning int[], return FailedRecord[], that is, an array (or List) of FailedRecords, where FailedRecord is something like:
> 
> public class FailedRecord {
>   private int position; // failed record index in the batch
>   private Exception reason; // (sql) exception describing the reason for failure
> ...
> }
> 
> In case if there are no failures, return an empty array/List.
> 
> Regards,
> 
> 
> 
> _______________________________________________
> No banners. No pop-ups. No kidding.
> Make My Way  your home on the Web - http://www.myway.com
> 
>