Hello all,

I have been digging in the docs for a long time now and I don't think I have got a satisfactory answer to a question which at least to me seems rather basic and central...

How well does Hibernate coexist with database-side "data-altering" foreign key constraints, say, an on delete cascade? I am building an app where the database should shoulder as much of the data integrity burden as possible as it will be concurrently accessed by different kinds of clients. As far as I can understand, there is no way for Hibernate to know that some rows have just for example automagically disappeared from the base because a referred-to row was deleted?

I would think that at least the optimistic locking versioning gets screwed with db-side on delete update, as this does not update version numbers?

Interesting, we just started talking about this very same issue :)

Right now, no, Hibernate does not understand that underlying database objects may have altered rows upon DML operations. But really, do have Hibernate "understand" this (in the way I think you mean understand) would be suboptimal, as it would mean that Hibernate would need to immediately re-read any rows involved in DML operations. Not gonna happen. Where this really gets messy is when mapping an association with cascading deletes and enabling CASCADE triggers in the database.

However, user code can perform like functionality by either 1) evicting the entity from the session and re-reading it, or 2) refreshing the entity.


Well the versions are still the same in the database as it is in the java memory space. So if by "screwed up" you mean Hibernate will let you continue with operations against that entity, then yes that is correct. But how can this be any different? Optimistic locking, by def, is an application concern to manage (Hibernate simply provides some powerful help wrt this). Think about hand-coding an optimistic locking strategy using JDBC; how would you handle it? Again, the safest way is to re-read rows after DML, which is extremely inefficient.


Cascading deletes is the only such "data-altering" FK constraint I am aware of. Did you have others in mind? Currently, if an association is defined in the database with a cascading delete trigger I would not map this in Hibernate using any of the delete cascade values.