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