Hibernate Version = 3.0.5

What is the difference between on-delete="cascade" in a key and cascade="delete" in a collection mapping? It seems that on-delete="cascade" generates a statement in the generated schema whereas cascade="delete" does, well, what, exactly?

Where I am going with this is I have a one-to-one mapping which expresses a parent-child relationship. I would like a on-delete="cascade" behavior on this, but there is no way to do this without a <key> in <one-to-one>.

on-delete="" is used by hibernate tools to add a constraint to the datbase. It has no effect on runtime hiberante.

cascade="" makes hibernate do various things to entities in an association or collection, when those same things are done to the owning entity.

If you want hibernate to issue a delete statement on a child when the parent is deleted, then you use cascade="delete". If you want the database to delete the child without any intervention from hibernate, use on-delete="cascade". However, that second option only works if you build your database using hibernate.

OK, that makes sense.

I do create my schema with Hibernate.

So, let me extrapolate your answer back to my second question and see if I have it right:



So if I have a <one-to-one> in which I want the child to be deleted automatically when the parent is, there is no way to have Hibernate generate a schema that would allow the database to handle this automatically.

My choices are therefore

to have Hibernate do it by using cascade="delete" or

to alter the schema to put an on-delete="cascade" on the foreign key declaration as Hibernate would do if it allowed the on-delete="cascade" if this were a collection with a key instead of a one to one.

Right?
Any recommendation one way or the other?

Either of those would work. There may be a <meta> attrbiute that you can put on the one-to-one that hibernate tools will read, and generate a CASCADE property on the relationship; I don't use hibernate tools, so I can't say. I assume that the tools have documentation describing the various ways to configure its operation.

Thanks.

meta, huh? I was looking at that but didn't really understand what it did.

One more question:

Is there a downside to putting both on-delete="cascade" on the key and cascade="delete" or "all-delete-orphan" etc. on the collection mapping?

<meta> is the element that runtime hibernate ignores, so other apps that use .hbm.xml files (e.g. hbm2ddl) can use it. I've never used any other apps that use .bhm.xml files, so I don't kow what values of <meta> are useful.

The only downside is that hibernate will issue redundant deletes: or rather, than the database cascade will never be used because hibernate will already have "manually" deleted anything that would have been cascade-deleted. It does mean that you can later remove that database cascade and nothing will break.

Generally, database cascades are preferred by "old school" database users, and more recent users prefer to do all of that in business logic.. or in this case, have hibernate do it for you.

Here's the thing: I want to maintain a very loose association between A and B. Ordinarily I would not want to make this association bidirectional. A has a B, but I never want to load that B when I load an A. My ONLY reason for making A hold a reference to B is so that I can delete the B when I delete the A from the database. This is a FREQUENT occurrence.

I find that the absence of on-delete="cascade" from the <one-to-one> is a serious lack, and wish Hibernate would implement it there. Otherwise I am forced to load B just to delete it, when I have no other reason to load it.

From up-thread a bit:

Can anyone either confirm the viability of the suggestion that there may be a <meta> attribute that I can use to embed cascade delete semantics on a <one-to-one>? If not I will have to either modify the generated schema or use hibernate cascades.

And by the way, this applies to Hibernate 3.0.5.