I'm using Hibernate tools 3.2.2.Beta1 running hbm2hbmxml from ant against MySQL 5.0.51a-community-nt-log

I was working with hibernate.reveng.xml and found that for some reason, when I specify:



In my resulting .hbm.xml mapping file I get duplicate <set>s for the "children":



The <many-to-one> is generated perfectly as name="parent" so I'm half-way there. I was not expecting the second set: children_1.

If I specify nothing (no <foreign-key>), I get the correct <many-to-one> and <set> code (one of each), but the property name is businessUnit and businessUnits respectively which would work, but I'd really like to call them parent and children if possible.

For reference, here is the table creation statement (irrelevant fields removed). Notice that it is a self-joining table - I wonder if that has anything to do with it?



What am I doing wrong?

my guess is that the foreignkey name is spelt differently, e.g. case sensitive.

if we dont find a match we assume you are defining a new foreignkey.

As a result of your posting, I made the following changes to hibernate.reveng.xml and everything now works just as I had wanted:



My two hang-ups were:

1.) I wasn't clear on the difference between the "constraint" name and the "foreign key" name (I'm still not, but now I know one reason why the difference is important).

2.) I hadn't expected the reverse engineering tool to share code with something that would try to create a new constraint while it was reverse engineering my database. This caused me to misread the manual (section 5.2.4.3. <foreign-key>) here:

http://www.hibernate.org/hib_docs/tools ... ering.html

Thank you very much!

1) constraint-name was chosen since that is what is used in most sql dialects for the name of foreign keys, primary key, unique constraints, check constraints etc.

2) We don't try and create a new constraint, we just interpret a non-matching foreign-key as something you then want to have as foreign-key...usecase is for older mysql or systems run by DBA's that thinks foreign keys are bad - here being able to state what constraints is actually there even though the db says they are not becomes usefull.

Constraint-name is perfect - don't change a thing! MySQL uses a separate constraint name and foreign key name. The constraint name has to be unique within the database so it's automatically assigned the tablename_ibfk_1 where the "1" is a sequence number incremented for each new constraint. If I drop and recreate a table in development, but merely add a new column in test, then the sequence numbers could be different in different environments and issuing a command to change a constraint in one environment will change a *different* constraint in another environment. This would be really bad.

To avoid this, I use the following template to declare a foreign key with MySQL InnoDB (the default database, MYISAM ignores the "on-delete cascade" clause):



That way I'm sure that the constraint name (which is what I have to reference in the Hibernate file) will not change. My confusion arose from having to sometimes refer to `process_fk_company` as a constraint (when adding a constraint) and sometimes as a foreign key (when dropping a constraint) in MySQL. That's not Hibernate's issue, though a little note to MySQL users in the reverse-engineering documentation for <foreign-key> would be helpful. The note might be something like:

5.2.4.3. <foreign-key>
...
(1) constraint name:
...
MySQL users: The constraint name is not the same as the foreign key name. To find what constraint name is used for a given foreign key, use the SHOW CREATE TABLE command. Constraint names in mysql look like `tablename_ibfk_1`.

If you point me to the proper place to request such a change I can work on getting it added... If you think it's a good idea.



Oh, OK. So hibernate.reveng thinks I'm trying to declare a foreign key relationship in the mapping file then it finds a foreign key in the database and shows both in the generated file. Makes sense. I can't imagine why someone would want to use a "database" without foreign keys, but I believe it. I've been forced to do worse things in my career.

Thanks so much for reading my posts so carefully and taking the time to clarify these issues.

Any idea on how to keep the reverse engineering process, in the Hibernate Tools plugin for Eclipse, from generating unwanted sets in my hbm.xml files?

Thanks!

After reading the Hibernate Tools Reference Guide section 5.2.4.3 "<foreign-key>" a little more closely, I discovered that you can limit the set associated to a class during the reverse engineering process.

Now all I have to do is understand the syntax a little more better. Hopefully this post will help me do that.

Okay guys. I just wanted to report back and say that because of this post, I am now able to successfully omit set from certain classes.

Thanks a bunch!

No problem!