I did not find any info about "referential integrity" in the hibernate online manual. There is a little discussion about that in Chapter 4 of the book "Hibernate in Action", but I still have the following confusion. Any help is greatly appreciated!

1. The "cascade=xxx" property of the association tags (e.g., <set>) is about cascade persistence, but not about SQL referential integrity, right?

2. It is impossible to specify referential integrity constraints (e.g., "... ON DELETE CASCADE", "ON DELETE SET NULL", "ON UPDATE CASCADE", etc.) in hibernate mapping, right?

3. It is also impossible to specify these constraints in XDoclet so that it can generate .hbm.xml, from which the exported SQL schema could contain the expected constraints (e.g., "... ON DELETE CASCADE") I want, right?

4. If I understand the above 3 questions correctly, in order to make the SQL schema script contains the expected constraints (e.g., "... ON DELETE SET NULL"), I have to take the exported schema and add these manually, right?

5. For example, class A {integer id;} and class B {integer id; integer idA}. I map A and B into two tables and B.idA has an association (with cascade="all-detele-orphan" set) to class A. I load an instance a of class A and a is the only instance in the current session (I did not load any instances of class B at all). Then I delete a with Session.delete(a). If there is a certain instance b of class B (in database but not loaded) that reference a, now b.aID will contain an invalid reference to a, right? Hibernate won't handle this integrity violation and it has to be handled by DBMS, right?

Thank you very much!
Stan

You can not use the ON <foo> functionality of your database with Hibernate (or any other "full" ORM tool) at the moment.

But how about I add the "ON DELETE xxx" referential integrity constraints maunually to the schema generated by the hibernate tools? This way, hibernate totally depends on the DBMS to ensure the integrity.

Thanks!

This way, Hibernate will break, since it can not detect the fact that the database internally deleted some dependent rows by cascading. The in-memory state of a Session can then no longer be synchronized with the database state.

I see. But in the book "Hibernate in Action", chapter 4.3.2, paragraph 4, it mentioned that "...hibernate partially delegates referential integrity concerns to the foreign key constraints of the underlying relational database...". I don't know that works. Could you please give a hint or any URL link where I can learn how partially (or fully if possible) I can solve the referential integrity (e.g., cascade delete or SET NULL on delete) when using hibernate?

One more thing to make sure. Suppose uni-direction association "A-->B". Referential integrity means "when B gets deleted, A should be taken care of (SET NULL or DELETE CASCADE)". But the cascade="delete" of "cascading persistence of hibernate" means "when A gets deleted, B should be taken care of (also deleted)". Am I correct?

Thank you very much for your great help!
Stan

Yes to your last paragraph.

Referential integrity means two things:

First, a constraint, that is, a guarantee that a referenced row has to exist for the current row to be valid.

Second, there are _options_ that make life easier for application developers, namely ON CASCADE <do something>. Since Hibernate takes care of that aspect for you, you don't have to implement it in the database (you actually shouldn't). This doesn't break integrity, since the constraint is what you are primarily interested in.

It might be possible that Hibernate will at some point be able to deal with ON CASCADE options, but this would be a special case where you have to turn off Hibernates lifecycle/interceptor/cascading for the relevant entity, because the database takes care of this issue.

1. Further make sure that to my understanding, "referential integrity" is in the reverse direction from "cascading persistence". For the original example 1-to-1 association "A-->B" (A references B), "referenctial integrity" cares about the deletion of B, but "cascading persistence" cares about the deletion of A. Right?

2. Three typical "Referential integrity" constraints are: "disallow deletion of object still being referenced", "delete cascade on delete", and "set null on delete". (to my understanding, the "cascade" here is different from the one in "cascading persistence" as shown in bullet 1 above). If I understand correctly, currently Hibernate depend on DBMS to do the default constraint ("disallow deletion of referenced objects"), and it doesn't support the other two constraints ("delete cascade on delete" and "set null on delete") in DBMS, otherwise it breaks.

Conclusion is that, hibernate may support more "on delete" functionalities in the future. But for now, it only support the default constraint "disallow deletion of object still being referenced" (which I verified with a sample testcase, in which when I tried to delete B, I got an JDBC SQL exception saying ERROR: update or delete on "B" violates foreign key constraint "fkc4d26af2552dfa2" on "A").

So when I use hibernate, if I want to delete an object referenced by other objects, I have to update all referencing objects to point to elsewhere so that the object I want to delete is no longer referenced by anyone else.

I think I understand it clearly now, don't I? Please correct me!
Thanks a lot!
Stan

You almost got it, but read my posting again: There are no different types of referential integrity. A constraint is a constraint. Everything else is an option.

Oh, yeah, I agree about the "constraint" concept. My wording is not that good :) Thanks for correcting me and all your help!
Stan