hibernate-issues

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

[Max R. A. (JIRA) <no...@at...>]

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

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

[Paul H. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1792?page=comments#action_23195 ] 

Paul Hicks commented on HHH-1792:
---------------------------------

It'd be best if the user had the option..  are you imagining that it will be possible for the user to do either of these, depending on his own preference?

Either:
    <sql-delete callable="true">{? = call stpDeleteThing(?)}</sql-delete>
Or:
    <sql-delete callable="true">{call stpDeleteThing(?)}</sql-delete>

If hibernate detected and allowed for the presence of the leading ?=, that would be ideal.


> 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

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

[Max R. A. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1792?page=comments#action_23197 ] 

Max Rydahl Andersen commented on HHH-1792:
------------------------------------------

Why do you want to keep the option ? The old way was broken. Did you use it ?

the leading ? = is oracle stuff and not relevant in respect to delete/insert/update since they do not return anything (except this currently non used out paramater at index 1)


> 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

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

[Max R. A. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1792?page=comments#action_23209 ] 

Max Rydahl Andersen commented on HHH-1792:
------------------------------------------

we will probably implement 

<sql-insert callable="true" rowcount="true|false"> 

> 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

[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

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

[Max R. A. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1792?page=comments#action_23384 ] 

Max Rydahl Andersen commented on HHH-1792:
------------------------------------------

"none" is probably the most sensible default, but it breaks backwards compabilityu.

I'm definitly +1 for "none" as default if old users code expliciitly fails with this default.

...and since we haven't received any feedback on planning on changing this I don't think many users will be affected....and 3.2 is a release that
is allowed to break things; especially since check="param" is available.



> 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