I have a schema like this:

A -> B -> B_C <- C

Where '->' means 'one to many' and '<-' means 'many to one' (in other words, the arrow is points towards the many side). B_C is an association table between B and C, establishing many to many multiplicity.

My classes and mappings for this schema look like this:

A -> B <-> C

That is to say, there is a one-to-many mapping between A and B, and a many-to-many mapping between B and C. Both mappings are bidirectional.

The association A -> B is mapped using cascade="all,delete-orphan". That means when I add a B to A's collection of Bs, it gets persisted, and when I remove a B from A's collection of Bs, it (should) get deleted.

The problem arises when I try to delete some Bs from A's collection of Bs. The operation cascades down the A -> B association and tries to delete Bs, but it is prevented by this foreign key constraint:

A -> B -> B_C <- C

The rows in the association table prevent Bs from being deleted. Of course, the first thing I tried doing is putting cascade="delete-orphan" on the

A -> B <-> C.

You can imagine what a bag of laughs that resulted in.

My question is this: How can I tell Hibernate to delete rows in the association table (B_C), but not in the many-to-many target table (C)? Is this possible without exposing B_C as its own class, and splitting up the many-to-many?

i have the same problem.

I waiting for any solution

I would definitively define a B_C class.

You never know when you will need extra information on the association itself. Hibernate doc recommend it anyway. Also, if you want a surrogate key on the join table, this is necessary anyway. With that class, you would be able to define cascading semantic for the join table itself and resolve your problem.

Remove B from A, delete row in B, but the B_C integrity is violated. What you need to tell hibernate is to delete the B_C link before deleting B. You can do that with the B_C Class. The collection of C in B will become a one-to-many to B_C with cascade behavior "all-delete-orphan" (just like A to B)

When removing B from A, B_C will first be removed, then B and voilà.

As I said, it is always a good thing to have a class for the join table. Think about it, the B_C link is an entity by itself (it may have a surrogate key, fields, have cascading behavior).

Let me know about it,