Hi guys!

I have a problem with a simple joined-subclass. Let A be the parent class and B its child (using joined-subclass, of course).

If I delete b, instance of B, the corresponding row in table A is not deleted !! After using my application for a while, table A gets full of orphan rows.

How can I solve this problem? I'd like to continue using joined-subclass.

Thanks!

Hibernate version:
3.0.5

If I get it right, the fact that A is not deleted is normal, because A could be used by another subclass.

What you should do, I think, is create your own delete method wich should be in your 'B' DAO. Your delete method should do something like this :

public void delete(B b)
{
A a = retrieve a from b id (they should have the same id)

delete b
if a has no more child then
delete a
end if
}

Maybe you can try deleting A directly instead, it will surely delete b too.

I hope this helps you out

Francois Archambault

Have you tried using cascade="all-delete-orphan"? That may solve your problem.

My objects are not inside a collection, so it cannnot be used.

Thanks.

Are you sure? I'm talking about a single istance of class B. Since B derives from A, and B is mapped using joined-subclass, part of the fields of that instance are saved in table A, part in table B.

When I delete that instance, why is the corrisponding row in table B deleted and the one in table A isn't?

The pending row in table A can't be shared with other objects, since it belongs ONLY to the instance just deleted.

I think you are right, A can not have any other subclass for that single row, but it can be used somewhere else.

Y'know what: if you actually show your mappings, and other needed information such as code and Hibernate log, then people might actually be able to give you useful advice.

http://www.hibernate.org/ForumMailingli ... AskForHelp

Ok, here's the mapping:

<class name="A">
<id name="id">
<generator class="increment" />
</id>
<property name="name" />
<property name="surname" />

<joined-subclass name="B">
<key column="id" on-delete="cascade" />
<property name="phone" />
</joined-subclass>
</class>

When I insert a record of class B, two rows are actually written in the DB (I think it's ok). But when I delete that record, the corresponding row in table A is NOT deleted.

I hope it's enough and you can help me.

Thank you.

So, since you have written on-delete="cascade", you must have a foreign key constraint with ON DELETE CASCADE in the database.

Did you read the documentation about the on-delete attribute before putting it in your mapping file?

Yes, I read the documentation. The database is 100% generated (and regenerated every time) by Hibernate.

WITH on-delete="cascade" in B's key, table B has an additional foreign constraint (ON DELETE CASCADE) that, when corresponding A record is deleted, B record is also deleted.

WITHOUT on-delete="cascade", that constraint in table B is not present.

My problem is the opposite. When an object of class B is deleted, its row is deleted from table B, but not from table A.

Either using on-delete="cascade" or not, the problem is not solved :-(

Thank you.

I don't believe you.

See the unit test in org.hibernate.test.ondelete.OnDeleteTest.

You should, I've just discovered we are both right. The testsuite works as expected, but my application continued to have this strange behaviour.

The problem is related to heritance AND collections, and it's an half bug of Hibernate or, maybe, something you should avoid to do.

Have a look at this example.

Class A { ... }
Class B extends A { ... }

This heritance tree is mapped using joined-subclass and on-delete="cascade".

As in your testsuite, when I manually delete an object of class B, Hibernate issues a "delete from A": since the cascade is enable, the row in B is also deleted. Ok :-)

Let's add another class:

Class C {
...
private Set setOfObjectsOfClassB;
}

In this class, the set of objects of class B (not A !!!) is mapped using a <set> with on-delete="cascade" enabled.

When I delete an object of class C, Hibernate issues only a "delete from C" SQL statement. Since the cascade is enabled, the database also delete every row of B linked to that instance of class C, but NOT THE CORRESPONDING rows in A, since there's not a cascade mechanism ad database level from B to A. That's why I find pending rows in A.

If I DON'T specify on-cascade="delete" in the collection, Hibernate removes B objects manually before removing C, so it correctly issues "delete from A", then a "delete from C".

I think this is an half bug of Hibernate. I solved the problem not using the cascade on the collection, but there should be some cascade from B to A in the database. Unfortunately, I'm not sure this is possible.

Thanks for your help.

For Collections, you might want to look at cascade="delete-orphan".

Clearly, this was a bug in your data model, not in Hibernate, since SQL-level ON CASCADE DELETE cannot be used like this.

Notice also, that this issue would have been resolved so much more quickly if you would have bothered to mention all the relevant details (like ... that it was a delete cascaded via a collection), and shown *all* mappings.