[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2722) incorrect sql on custom types when using dynamic update, optimistic-lock="dirty", select-before-update when null value in where clause

Alex McCarrier (JIRA) noreply at atlassian.com
Thu Jul 12 11:47:52 EDT 2007


    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_27468 ] 

Alex McCarrier commented on HHH-2722:
-------------------------------------

One more comment that might have some relevance.  The field that is mapped that is having problems is actually a primitive field.  This might be what is throwing off the determination of whether to use "is null" or not.  What we have is a custom type that for fields that are null in the database, returns 0 in the mapping.

> incorrect sql on custom types when using dynamic update, optimistic-lock="dirty", select-before-update when null value in where clause
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HHH-2722
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2722
>             Project: Hibernate3
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.2.2
>         Environment: hibernate 3.2.2, oracle 10g
>            Reporter: Alex McCarrier
>            Priority: Minor
>
> We are using optimistic-lock="dirty", dynamic-update="true" and select-before-update="true" on some of our classes.  This seems to be isolated to cases where we are using custom types that implement the UserType interface.
> The SQL that is generated by hibernate for the PreparedStatement looks something like this:
> delete from TABLE_NAME where PK = :1 and SOME_NUMBER = :2
> The problem happens when the value for SOME_NUMBER is null.  It still tries to use the above sql, rather than using the correct:
> delete from TABLE_NAME where PK = :1 and SOME_NUMBER is null.
> In this case, SOME_NUMBER is defined in Oracle as a FLOAT, and in the mapped object as double.  Interestingly, another one of our custom types which is a Binary type (Hibernate.BINARY.sqlType) has no problems.

-- 
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

        



More information about the hibernate-issues mailing list