ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lamey <cla...@localmatters.com>
Subject Re: public int executeBatch()
Date Thu, 01 Jun 2006 19:02:15 GMT

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


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

View raw message