Why has Hibernate switched to use LONG over CLOB?

Question

It looks like that Hibernate started using LONG data type in version 3.5.5 (we upgraded from 3.2.7) instead of CLOB for the property of type="text".

This is causing problems as LONG data type in Oracle is an old outdated data type (see http://www.orafaq.com/wiki/LONG) that shouldn’t be used, and tables can’t have more than one column having LONG as a data type.

Does anyone know why this has been changed?

I have tried to set the Oracle SetBigStringTryClob property to true (as suggested in http://stackoverflow.com/questions/1843484/hibernate-clob-oracle), but that does not affect the data type mapping but only data transfer internals which are irrelevant to my case.

One possible fix for this is to override the org.hibernate.dialect.Oracle9iDialect:

public class Oracle9iDialectFix extends Oracle9iDialect {
  public Oracle9iDialectFix() {
    super();
    registerColumnType(Types.LONGVARCHAR, "clob");
    registerColumnType(Types.LONGNVARCHAR, "clob");
  }
}

However this is the last resort - overriding this class is step closer to forking Hibernate which I would rather avoid doing.

Can anybody explain why this was done? Should this be raised as a bug?

[UPDATE]: I have created http://opensource.atlassian.com/projects/hibernate/browse/HHH-5569, let's see what happens.

Answer 1

Can anybody explain why this was done? Should this be raised as a bug?

This has been done for HHH-3892 - Improve support for mapping SQL LONGVARCHAR and CLOB to Java String, SQL LONGVARBINARY and BLOB to Java byte[] (update of the documentation is tracked by HHH-4878).

And according to the same issue, the old behavior was wrong.

(NOTE: currently, org.hibernate.type.TextType incorrectly maps "text" to java.sql.Types.CLOB; this will be fixed by this issue and updated in database dialects)

You can always raise an issue but in short, my understanding is that you should use type="clob" if you want to get the property mapped to a CLOB.

PS: Providing your own Dialect and declaring it in your Hibernate configuration (which has nothing to do with a fork) is IMHO not a solution on the long term.