For a simple test case, I found precision and scale aren't taken by Hibernate Tool 3.2 beta 8 with MySQL 5. Here is my test case (pay attention to "test" field),

CREATE TABLE `test` (
`id` int(5) NOT NULL,
`test` smallint(2) default NULL,
`comment` char(1) default NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

<hibernate-reverse-engineering>
<schema-selection match-table="test"/>
<type-mapping>
<!-- jdbc-type is name fom java.sql.Types -->
<sql-type jdbc-type="CHAR" length="1" hibernate-type="yes_no"/>
<sql-type jdbc-type="SMALLINT" hibernate-type="java.lang.Integer"/>
</type-mapping>
<!--sql-type jdbc-type="SMALLINT" precision="2" scale="0" hibernate-type="java.lang.Integer"/-->
<table name="test">
<primary-key>
<generator class="native"/>
</primary-key>
</table>
</hibernate-reverse-engineering>

Form log file I noticed this difference,

1. Without precision and attribute specified

[hibernatetool] (cfg.JDBCBinder 803 ) Building property id
[hibernatetool] (cfg.JDBCBinder 542 ) Scanning org.hibernate.cfg.reveng.TableIdentifier(test) for <version>/<timestamp> columns.
[hibernatetool] (cfg.JDBCBinder 552 ) No columns reported while scanning for <version>/<timestamp> columns in org.hibernate.cfg.reveng.TableIdentifier(test)
[hibernatetool] (reveng.OverrideRepository 312 ) columnToHibernateTypeName, <type-mapping> found: java.lang.Integer for Table: test column: test
[hibernatetool] (cfg.JDBCBinder 635 ) Sql type mismatch for Table: test column: test between DB and wanted hibernate type. Sql type set to 5(SMALLINT) instead of 4(INTEGER)
[hibernatetool] (cfg.JDBCBinder 803 ) Building property test
[hibernatetool] (reveng.OverrideRepository 312 ) columnToHibernateTypeName, <type-mapping> found: yes_no for Table: test column: comment


2. With precision and attribute specified
[hibernatetool] (cfg.JDBCBinder 803 ) Building property id
[hibernatetool] (cfg.JDBCBinder 542 ) Scanning org.hibernate.cfg.reveng.TableIdentifier(test) for <version>/<timestamp> columns.
[hibernatetool] (cfg.JDBCBinder 552 ) No columns reported while scanning for <version>/<timestamp> columns in org.hibernate.cfg.reveng.TableIdentifier(test)
[hibernatetool] (cfg.JDBCBinder 803 ) Building property test
[hibernatetool] (reveng.OverrideRepository 312 ) columnToHibernateTypeName, <type-mapping> found: yes_no for Table: test column: comment

Is it a bug?

hmmm...could you put this in jira and i'll look into it.

either we have a bug or precision/scaling is reported wrong by mysql.

at least i need to improve the logging so you actually can see why its finding/rejecting the reveng.xml setup.

Done at http://opensource.atlassian.com/project ... se/HBX-828

Looks to be a bug in the OverrideRepository.getPreferredHibernateType method and the TypeMappingKey inner class. The TypeMappingKey has no references to precision and scale, only length, so precision and scale will never be analyzed for matches in the reveng file.

As a workaround for now, implement the columnToHibernateTypeName method in a custom Strategy class thusly:

I added one line output code and it shows me precision is 19 instead of 2 for test column even though I defined precision 2 for it in db. Any idea or any workround?

@Override
public String columnToHibernateTypeName(TableIdentifier table, String columnName, int sqlType, int length, int precision, int scale, boolean nullable, boolean generatedIdentifier) {
System.out.println("columnName/type/precision ------- "+columnName+"/"+sqlType+"/"+precision);
if ((sqlType == java.sql.Types.SMALLINT) && (precision == 2)) {
System.out.println("Got it!");
return "java.lang.Integer";
} else {
return super.columnToHibernateTypeName(table, columnName, sqlType, length, precision, scale, nullable, generatedIdentifier);
}

Console log,

[hibernatetool] columnName/type/precision ------- id/4/19
[hibernatetool] (cfg.JDBCBinder 803 ) Building property id
[hibernatetool] (cfg.JDBCBinder 542 ) Scanning org.hibernate.cfg.reveng.TableIdentifier(test) for <version>/<timestamp> columns.
[hibernatetool] (cfg.JDBCBinder 552 ) No columns reported while scanning for <version>/<timestamp> columns in org.hibernate.cfg.reveng.TableIdentifier(test)
[hibernatetool] columnName/type/precision ------- test/5/19
[hibernatetool] (cfg.JDBCBinder 803 ) Building property test
[hibernatetool] columnName/type/precision ------- comment/1/19

Now that is funky! I'll take a gander at it and see what I can come up with. Lemme run a reveng on my data (400+ tables) and see what the reported precisions are, that'll give me an idea as to whether it is the tool code or the jdbc driver.

I don't think it is a driver issue. I used the same driver(3.1.12) with beta 3 or 4(I can't remember exact tool version) and it worked fine. I have tried both latest 5.0.3 driver and 3.1.12 driver, and I got the same precision=19.

Aha. The JDBCToHibernateTypeHelper does not list Types.SMALLINT as having scale or precision (only DECIMAL, NUMERIC, REAL, FLOAT, and DOUBLE have these attributes at the moment)! This may or may not be a bug, but I will JIRA it with a patch and hopefully it will get included in the next iteration. in the meantime, I would use some sort of workaround, even if you have to modify the columnToHibernateType to specify the return type based on the table and/or column name. If you want all SMALLINTs to be java.lang.Integers then just remove the precision conditional.

Confusion with customized strategy is,

1. why do I have length 19 for all columns?
2. how can comment column be converted properly from char(1) to yes_no type even it shows length 19 here? where did this conversion occur?

1) 19 is the default precision for column types with no precision
2) the reported precision for the comment column is 19, the length will be 1

Patch added to JIRA HBX-828