I have an interesting finding in 3.2beta8 and MySQL 5 in hbm2hbm case in ant env.

1. If I enable hibernate.default_schema=xxx OR hibernate.default_catalog=xxx in hibernate property file to generate catalog attribute in class element of hbm file, I got return type for id as below,

<id name="id" type="int">

if I enable both hibernate.default_schema=xxx AND hibernate.default_catalog=xxx, I can't get catalog attribute any more. Generated id is like,

<id name="id" type="java.lang.Integer">

In these two cases, even I put following in rev. template file it is yet taken.

<sql-type jdbc-type="DECIMAL" precision="7" scale="0"
hibernate-type="Integer" />(or "java.lang.Integer")

So why id type is associated with catalog attribute?

2. In non-id field, similar problem occurs based on if column's field is allowed for NULL. If NULL is allowed, that field will be mapped to a wrapper class type; otherwise it will be mapped to primitive type. For example,

city smallint(4) YES (for NULL)
county smallint(3) NO (for NULL)

I got following mapping,

<property name="city" type="java.lang.Short">
<column name="city">
<comment></comment>
</column>
</property>
<property name="county" type="short">
<column name="county" not-null="true">
<comment></comment>
</column>
</property>

Why do we have such an inconsistence in hbm generation?

Generally, item 1 affects my work since hibernate needs a wrapper class type to determine if it is a new record or existing one; Item 2 doesn't since java will handle conversion between primitive type and its corresponding wrapper, but I want to know why it is inconsistent.

ok.



Yes, since you have told the tools which catalog should be considered the default and thus it will not include the default catalog in the output - if you had two catalogs the other one would be in the output.



And what is the chosen strategy ? are they the same ?

"int" is normally chosen when the generator is assigned which means the id cannot/should not be null.

With a generator id's should be allowed to be null.



Probably because your column is not being reported as DECIMAL, 7, 0 from mysql (the most likely cause)



You need to show the reveng.xml and more of the generated output for me to be more conclusive than the suggestions above.



Sorry, but what is the problem ? if not-null="true" then the primitive version is chosen because it cannot be null.

If you want to override it you need to have a type-mapping that matches and i think you don't have that.



Hibernate 3 does not need such thing.



I don't think its inconsistent, it follows the not-null definition by default.