The Category.hbm.xml makes a reference to FK1_GROUP_USER_ID, which is not part of the schema. Is that an error?

Where?

oops, I meant FK1_CATEGORIZED_ITEM_ID

as in <key foreign-key="FK1_CATEGORIZED_ITEM_ID">
<column name="CATEGORY_ID" not-null="true" length="16"/>
</key>

Read up on what the foreign-key attribute does.

I read the documentation at http://www.hibernate.org/hib_docs/reference/en/html/

but all I could find about the foreign-key attribute was this:

foreign-key foreign_key_name specifies the name of the foreign key constraint generated for an association, use it on <one-to-one>, <many-to-one>, <key>, and <many-to-many> mapping elements. Note that inverse="true" sides will not be considered by SchemaExport.

Is there another place I can read up on this so I can understand why this key seems to be invisible to the schema?

Alex

Its just a name. If you don't use the attribute, the FK constraint will get a different, auto-generated name. Its not about turning the constraint on or off.

And, if this isn't obvious, this is only relevant if Hiberante's SchemaExport generates the database schema and the constraints. It doesn't matter much if you have an existing schema.

Well, that's exactly why I am puzzled: I generated my caveat emptor schema automatically using the "exportddl" ant build script target that you provided in the distribution. It worked well, but that foreign key does not appear anywhere on the DDL that got generated. I thought the generated DDL should be based on my mappings.

Because its inverse="true". You just pasted that part of the documentation...

I am confused. Then why is that attribute there? Also, I've read about the inverse=true in the documentation and all that but didn't realize that would be relevant to foreign key not being considered. Please elaborate or send me a link to the info that would clear up my understanding.

I'm not going to discuss this further, everything has been answered several times in this thread (and as I said, you already pasted the piece of documentation that is relevant). If you absolutely can't live with it, remove the attribute. It makes no difference. It makes a difference if you put the inverse="true" on the other side of the association, as described in the book.

Another tip: consider reading up on database basics to understand what the difference between a constraint and a constraint name is, you still don't seem to get that part.

I can live with it just fine, all I was asking is what effect it has, since it never made it into the generated ddl (and, yes, I know the difference between constraint name and constraint and nevertheless, my knowledge indicates that constraint names DO make it into the ddl.) Now, if your answer is: it would have an effect had the attribute on the other side of relationship been set to inverse="true" - that's a perfectly good answer - all you have to do is say just that. The expression of impatience, I believe, is unwarranted.