I'm using foreign keys just fine.
I'm not sure whether you're really hitting the same issue that was originally reported (my interest in Hibernate has been waning since I'm hitting a wall in support for long-running session, but that's an entirely different story).
Anyway, here's our setup:
We have two tables, ARTDSP, with PK FIRM/STOR/IDENTNR, and ARTSTA, with PK IDENTNR, with the obvious many-to-one FK constraint.
In hibernate.reveng.xml, it looks like this:
Quote:
<table name="ARTDSP">
<foreign-key foreign-table="ARTSTA" constraint-name="fk_artdsp_artsta">
<column-ref local-column="IDENTNR" foreign-column="IDENTNR" />
<many-to-one insert="false" update="false" />
</foreign-key>
We do have our troubles with that.
For one, we needed to carefully code around redundancy: the Artdsp class has both getId().getIdentnr() and getArtsta(); this is not an issue here because IDENTNR is a primary key and you can't call a setter on these without thoroughly confusing Hibernate's dirty checking (it gets confused about the identity of entities since it is using the primary key for that). However, we have FK constraints that are modifiable, and sometimes we have had to make both the raw ID value and the Java pointer available on the POJO side, and you need to be aware that the two need to be updated in lock-step. (Unfortunately, reveng doesn't generate setters that take care of it, and you can't easily subclass the generate code.)
Second, if the constraint is also in the database metadata, you need to use exactly the name that the database uses, else Reveng will think that the constraint in reveng.xml is another, separate one and create TWO links, one for the database one and one for the reveng.xml one. Easy to avoid if you're aware of this, but boy did I have a hard time figuring out why I got
Quote:
Artsta artsta;
Artsta artsta2;
in the generated code!
Third, there is a really fundamental difference between generating inline composite keys or having them separate. Inline keys means that in the above example, I have a firm, a stor, and an identnr field in Artdsp; separate keys means I have a separate ArtdspId class for firm/stor/identnr. Having separate Id objects is nice if you pass ids around a lot, but it sucks if you think at the table field level because the PK fields need to be prefixed with "id." whenever you need them in HQL or a Criteria query (but not if the PK happens to be a single field, in which case Reveng doesn't generate a separate class).
I'm not sure how much of this actually helps you, but here you go :-)