You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by "Martin Zeltner (JIRA)" <ib...@incubator.apache.org> on 2005/08/19 14:09:54 UTC
[jira] Updated: (IBATIS-159) Sql batch execution returns only one int with the total row count. Change it to int array, like it is made in java.sql.Statement.executeBatch()
[ http://issues.apache.org/jira/browse/IBATIS-159?page=all ]
Martin Zeltner updated IBATIS-159:
----------------------------------
Attachment: patch_19-08-2005.txt
I've improved the batch exception handling. Subversion patch is available in 'patch_19-08-2005.txt'.
> Sql batch execution returns only one int with the total row count. Change it to int array, like it is made in java.sql.Statement.executeBatch()
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: IBATIS-159
> URL: http://issues.apache.org/jira/browse/IBATIS-159
> Project: iBatis for Java
> Type: Improvement
> Components: SQL Maps
> Versions: 2.0.8, 2.0.9, 2.1.0, 2.0.9b
> Environment: WinXp
> Reporter: Martin Zeltner
> Attachments: patch.txt, patch_19-08-2005.txt
>
> The method "executeBatch" of "SqlMapExecutor" does only return one int value with summerized update counts. By this way we can say which batch statement(s) has produced a failure. Also the possibly thrown exception does not satisfy. I've added a method "executeBatchDetailed" in each necessary interface and class and have improved the thrown exceptions. For example the new usage would looks like in the following example:
> com.ibatis.sqlmap.client.SqlMapExecutor executor = ...
> executor.startBatch();
> executor.update("insertSomething", "myParamValue1");
> executor.update("insertSomething", "myParamValue2");
> executor.update("insertSomething", "myParamValue3");
> executor.update("insertSomethingElse", "myOtherParamValue1");
> executor.update("insertSomethingElse", "myOtherParamValue2");
> try {
> int[] rowCount = executor.executeBatchDetailed();
> /**
> * At this position the rowCount array contains five integers
> * which represents the number of rows affected or the value
> * java.sql.Statement.SUCCESS_NO_INFO if a batch statement could
> * be executed successfully but no information was available
> * (bad implemented jdbc driver).
> */
> ...
> } catch (MoreBatchUpdateException e) {
> int[] rowCountsOfMostAllBatchStatements
> = e.getMoreUpdateCounts();
> /**
> * At this position the rowCountsOfMostAllBatchStatements array
> * contains up to five integers and at minimum one integer has
> * the value java.sql.Statement.EXECUTE_FAILED. Normally a jdbc driver
> * throws a BatchUpdateException if a batch statement fails, but
> * in this case the jdbc driver has tried to execute all batch
> * statements of the same group. Groups could be "insertSomething"
> * and "insertSomethingElse" in this example. If a batch statement
> * of group "insertSomething" would fail, the array
> * rowCountsOfMostAllBatchStatements could contain three integers.
> */
> } catch (BatchUpdateException e) {
> int[] rowCountsOfOnlySuccessfulBatchStatements
> = e.getUpdateCounts();
> /**
> * At this position the rowCountsOfOnlySuccessfulBatchStatements
> * array contains only row counts of the successful executed
> * batch statement. If the last batch statement would fail, the
> * array would contain four integers in this example. This exception
> * was thrown by the jdbc driver and is the standard behaviour
> * how it should be.
> */
> } catch (SQLException e) {
> ...
> }
> I would be very glad if you would take over this improvement in next release.
> For added/changed files please have a look at attached "patch.txt" file.
> Cheers,
> Martin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira