I am using hiberrnate reverse engineering tool [HibernateTools-3.2.0.beta11] with oracle 9i DB which has column of type NVARCHAR. I use ant tasks <hbm2hbmxml /> and <hbm2java /> to generate mapping and java files.

In the hibernate.reveng.xml currently am using following mapping to convert nvarchar column to string.

<type-mapping>
<sql-type jdbc-type="OTHER" hibernate-type="string"/>
</type-mapping>

But with above aproach all the unknown JDBC/DB types including nvarchar will be convreted to String. I want to avoid this and instruct tool to convert only nvarchar to string. Is there any other way with which this can be achieved ?

If I don't use above <type-mapping> tag then all nvarchar columns will be converted to java.io.Serializable.

I tried extending Oracle9iDialect and used in the hibernate.cfg.xml file during reverse engineering without using <type-mapping> tag in hibernate.reveng.xml, but with no success. Below is the new dialect class which I used.

public class MyOracle9iDialect extends Oracle9iDialect {
public MyOracle9iDialect(){
super();
registerColumnType( Types.CHAR, "nchar(l)" );
registerColumnType( Types.VARCHAR, "nvarchar2($l)" );
registerColumnType( Types.CLOB, "nclob" );

}

}


Thanks.

the dialect only covers mapping from jdbc types to db specific names.

we don't have a specific dbtype to jdbc type mapping (yet)

you can use the scale/precision.nullable attributes to make it not pick all non-jdbc types.

--- the dialect only covers mapping from jdbc types to db specific names.


Is this dialect not being used during reverse engineering to get the hibernate/jdbc type mapping for db specific names ? Dialect which I had written maps nvarchar to Types.VARCHAR.


--- you can use the scale/precision.nullable attributes to make it not pick all non-jdbc types.

If I have many columns with different scale/precision then does that mean that <sql-type jdbc-type="OTHER" hibernate-type="string"/> has to be mapped for each and every column with right comination of scale/precision vlaue ?

Thanks

yes in the current form yes.

Thanks for the reply.

Reverse engineering uses JDBCMetaDataDialect. Is it possible to avoid use of <type-mapping> for nvarchar by extending JDBCMetaDataDialect and tweaking it ? Is there any scope to add type identification for nvarchar in the extended dialect class?

you can tweak JDBCMetaDataDialect to return something else for the columns if you want.