I use Hibernate Tools for generating domain code and mapping files.

Here's my scenario:
There's a table 'CODES' with a numeric primary key and another table (CODES_TRANSLATIONS) with a combined primary key (two parts - a numeric and a alphanumeric one).
The first part of the combined key references the primary key of the first table (1:n relationship - CODES=1, CODES_TRANSLATIONS=n).

For better understanding here's the DDL:


In the hibernate.reveng.xml I map the numeric types to java.lang.Long (in the database they have the same type, precision and scale).

In the Hibernate Code Generation dialog I select 'Generate basic typed composite ids'.

Hibernate Tools generates a class Codes, a class CodesTranslations and a class for the combined key - CodesTranslationsId.

Here's the strange thing I discovered:
The field sid in class Codes is of type java.lang.Long, BUT the field sidCodes in class CodesTranslationsId is of primitive type long.

When I deselect 'Generate basic typed composite ids', the class CodesTranslationsId has a reference to Codes.

When I select it again and just have generated the code for CODES_DESCRIPTIONS and NOT for CODES, the field sidCodes is of type java.lang.Long (the behaviour I desired), but, of course, the relationship between the two tables is not mapped either (which is expected behaviour, as I removed the table filter for table CODES).

My question is:
Is it a bug that Hibernate Tools generates a Wrapper Type for the one class and a primitive for another (even if it's mapped)?
Or is Hibernate Tools designed to behave like this - i.e. generating primitive types for Id-Objects?
Is there any possibility to have Hibernate Tools create a java.lang.Long in the Id class instead of primitives?

Is there probably a way to tell Hibernate tools not to generate Id-Objects?

try set nullable="true" on the type-mapping and let me know if that works for you.



I don't understand why you are removing some needed info and then expects the relationship to be there ?



not sure, would need to look into the code for the applied logic.



it does if it is not mapped otherwise.



try the nullable as explained above.



that is what "basic composite id's" are...

First of all: Thanks for help!


the actual name of the property is 'not-null'. I set it to "false", but the mapping was ignored. Now all numeric fields are of type BigDecimal.

Therefore, I checked the possible properties for the 'key-column' tag and I found out that one can explicitly map single columns with

The only disadvantage of this approach is that you have to write that entry for every single column you explicitly want to map.


I DID expect the relationship NOT to be there. Sorry, if I wrongly expressed myself.


Regardless of if you check 'Generate basic typed composite ids' or not, a Id-class is always created - in my case the class CodesTranslationsId with the fields sidCodes and code.

My question is, if there's the possibility NOT to have generated the class CodesTranslationsId and have added the fields sidCodes and code to the CodesTranslations class.

Here's the code Hibernate Tools creates for the .hbm.xml:


and that's the code, I'd like to have:



Is it possible to generate the code like this with Hibernate Tools? If yes, how?

sorry for taking so long - been a busy week ;)

The reason why it gets to be a long by default is because:

a) the column is not nullable

b) the property is an assigned id (all composite keys are assigned, not generated)

...both things that speaks: Can never be null.

Just so you understand the default handling ;)

So to override that you got several options:

1) override the column specifically (which I understand you already did but find to specific) in reveng.xml

2) use a type-mapping with a match on the right type and nullable set to "true" to handle it for all columns (you say this does not work for you but I can't reproduce that here so I would need a test case in jira to show that it fails)

3) Override the "assigned values is not-nullable by default" rule by writing a custom revengstrategy that does the following:



The dots are just all the parameters repeated, except the last one where you force it to always look like an generated id.

hope that helps, but I would definitly like to get a testcase where 2 does not work!