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