[hibernate-issues] [Hibernate-JIRA] Updated: (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)]

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

Alex McCarrier updated HHH-2722:
--------------------------------

    Attachment: HHH-2722.patch

Patch is in unified diff format.  Apply to .../src (3.2.4) or .../java (trunk) using "patch -p1" command.

Problem occurs in both trunk source code, and 3.2.4.  This patch fixes the issue with custom data types that could possibly return non-null values that represent a null database field when using optimistic-lock="dirty" dynamic-update="true"

> 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
>         Attachments: HHH-2722.patch, mylyn-context.zip
>
>
> 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