I'm running into an issue with mappings that I was hoping someone could point me in the right direction. I'm using the reveng tools to generate hbm's from an existing Oracle 9 database and generating pojo's & DAO's from those hbm's. The problem I'm seeing is say we have an id column defined in Oracle as NUMBER(5), when generating the it is being mapped to type 'int'. When the pojo is generated id is type int and hbm2dao is creating a method with the signature findById(int id). All is well, except the body of this method is calling session.get(class, int) when that method is expecting get(class, Serializable).

I've been trying to define mappings in the reveng.xml so NUMBER(5) would be mapped to 'integer' instead, but they haven't been working so I'm not sure that's the right approach or I just don't have the correct JDBC types being defined for the incoming type. I'm in the process of pulling those types now to make sure I have the right ones, I just wanted to make sure this is necessary and I'm not missing something obvious.

Also, is it possible to specify somewhere in the reveng.xml all tables matching *_TYPE should be read-only, and is that done just with the insert=false & update=false properties?

TIA!

Hibernate version:
3.2.3, tools version 3.2.0.b9a

Name and version of the database you are using:
Oracle 9i

Mapping excerpt:
<hibernate-mapping>
<class name="net.package.AddressType" table="ADDRESS_TYPE" schema="teh_schema">
<id name="id" type="int">
<column name="ID" precision="5" scale="0" />
<generator class="assigned" />

map it to java.lang.Integer (integer is the same as int, just takes longer to type ;)

Ahh, I see... I actually figured out why it wasn't picking the mapping up, and it was just because I didn't understand the SQL Types correctly and was trying to map NUMBER length="5" precision="0" rather than NUMBER precision="5" scale="0". For some reason I had misunderstood what "Hibernate type" was referring to and thought it was some type of mapping itself that would map to java.lang.Integer.

Once I realized my mistake with the mapping definition, I did try mapping to java.lang.Integer, however that was breaking everything that was already using those classes so I removed the mapping overrides and tried a different approach. Since I was already using a customized template for the DAO's, I changed the get() call in findById() to test the type of id and if it's a primitive to create the appropriate wrapper class for that type.



It really seems like this is something that should be being done in the default template since if id is a primitive type Session.get(class, <primitive>) is invalid (we're using JDK 1.42, I'm not sure what happens if jdk5 is set). If PRIMITIVES were exposed via a getter it would actually be much cleaner since it could be:



Then the value of safeId is passed into the 2nd param of Session.get() instead of id. Would this seem to be a legitimate fix for this issue? It seems to do the trick here, anyway...

Thanks!

but this won't work for ids that are not primitives!

The problem only exists for primitives, that's why you only apply the wrapper class if c2j.isPrimitive() is true. Otherwise you just use id.

ah sorry, i misread. sure - submit a patch to jira.