由于MS SQL中UNIQUE约束的非标准行为，Spring / Hibernate的解决方法

Question

There is a UNIQUE database constraint on an index which doesn't allow more than one record having identical columns.

There is a piece of code, managed by Hibernate (v2.1.8), doing two DAO
getHibernateTemplate().save( theObject )
calls which results two records entered into the table mentioned above.

If this code is executed without transactions, it results INSERT, UPDATE, then another INSERT and another UPDATE SQL statements and works fine. Apparently, the sequence is to insert the record containing DB NULL first, and then update it with the proper data.

If this code is executed under Spring (v2.0.5) wrapped in a single Spring transaction, it results two INSERTS, followed by immediate exception due to UNIQUE constraint mentioned above.

This problem only manifests itself on MS SQL due to its incompatibility with ANSI SQL. It works fine on MySQL and Oracle. Unfortunately, our solution is cross-platform and must support all databases.

Having this stack of technologies, what would be your preferred workaround for given problem?

Answer 1

You could try flushing the hibernate session in between the two saves. This may force Hibernate to perform the first update before the second insert.

Also, when you say that hibernate is inserting NULL with the insert, do you mean every column is NULL, or just the ID column?

Answer 2

I have no experience in Hibernate, so I don't know if you are free to change the DB at your will or if Hibernate requires a specific DB structure you cannot change.

If you can make changes then you can use this workaround in MSSQL tu emulate the ANSI behaviour :

drop the unique index/constraint

define a calc field like this:

alter table MyTable Add MyCalcField as 
case when MyUniqueField is NULL 
      then cast(Myprimarykey as MyUniqueFieldType) 
      else MyUniqueField end

add the unique constraint on this new field you created.

Naturally this applies if MyUniqueField is not the primary key! :)

You can find more details in this article at databasejournal.com