[Hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-1792) Callable update/insert/delete statements should not force rowcount out parameter

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1792?page=all ]
     
Steve Ebersole resolved HHH-1792:
---------------------------------

    Resolution: Fixed

Introduced a new "check" attribute on the pertinent DTD elements:
<!ATTLIST sql-insert check (none|rowcount|param) #IMPLIED>

none = perform no update-count checking
rowcount = perform update-count checking based on the value returned by executeUpdate()/executeBatch()
param = perform update-count checking based on an output parameter (legacy callable checking)

Should we make none the default for callable statements moving forward?

> Callable update/insert/delete statements should not force rowcount out parameter
> --------------------------------------------------------------------------------
>
>          Key: HHH-1792
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1792
>      Project: Hibernate3
>         Type: Deprecation

>   Components: core
>     Versions: 3.1.3, 3.2.0.cr2
>     Reporter: Max Rydahl Andersen
>     Priority: Blocker
>      Fix For: 3.2.0

>
>
> the current handling of <sql-insert>, <sql-update>, <sql-delete> when callable="true" is broken.
> It "forcefully" requires users to have an out parameter at the first position that returns the rowcount and then simply ignores it!
> This only became obvious when trying to use the sql-update on DB2 where executeUpdate returns -1 opposed to what is done
> on Oracle and MS SQL Server.
> We need to fix this by either:
> a) actually start using this value (which requires the SP to return an expected value which in most cases just will be 1 or 0)
> b) remove the need for this parameter and simply let the SP handle the error handling 
> I vote for B even though it will break backwards compability, since if they were using the old way they would either have failed on every operation (if running on DB2) or having the code silently ignore any possible update/delete rowcount mismatches.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira