ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Zeltner (JIRA)" <ibatis-...@incubator.apache.org>
Subject [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()
Date Fri, 19 Aug 2005 12:09:54 GMT
     [ 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


Mime
View raw message