I am just wondering on what the ideal way is to deal with such a situation.
I have an m:n mapping over a mapping table, which has extra attributes.
Dutyfully I mapped it to an m object a mapping object and an n object
so far so good.

Now I want to readjust the mapping at a certain stage of my program.

I now delete the associated mapping objects and reassign them.
Basically this works, but only in several cases.

Now to the problem, I am forced to use a compound key (project constraints)
now if I set the mapping to lazy,

deleting the objects via a deleta and reassigning them within the same session works.

Now if I turn off lazy, deleting them and reassigning them, results although a flush and clear was done in between, in an error, which basically says, that due to the cascade options a deleted object cannot be reassigned.

How is the ideal way to deal with this situation, for now I can live with lazy and doing it that way, but in the long run, I might be forced to set lazy to false and to run into the problem.

Come on people am I the only one who uses many to many relations?

Ok gotta answer myself, after digging deeper into the forum it looks like, that there is no other sane way to deal with many with explicit
declaration with a separate binding class and to use either a surrogate for the key or in case of a compound key, enforce a lazy = true
on the compound object.

In all other cases if you readjust the mapping and have some cascasdes Hibernate will choke...

Many-To-Many needs some additional documentation, it is a huge problem in Hibernate at the current state of affairs, with too many options which lead into cryptic error messages.

Aha... I've found your post! (It's josh from the MyFaces list)

If I understand you correctly, you are trying to delete objects and then re-point them at each other, correct?

If that's the case then it would make sense if it worked when lazy is 'true' because the objects being re-assigned are actually *proxy* objects, and the session needs to keep track of those slightly differently.

I could probably give you a better answer if you posted an example. :)

I think this is the ideal way to deal with this case.
another one is probably to resolve the issue by using a surrogate attribute in the binding table/object.

But what really is needed in the end, probably is following some kind of tool to resolve the m:n relational issues in a more transparent way...

something like
hibernatetools.reassignrelation(relationallist)

which does the resolvment of relational bindings more transparently without running into the cascade issues if you do not use lazy=true :-(

It is less a bug in Hibernate, Hibernate behaves correctly in what it should do, but more an issue of having a clear best practice and probably needing a layer on top of it which makes things less complex and error prone.

a) In the end a many to many resolvment should work somehow like that:

many1.setMany2s(List of many2s)
saveOrUpdate(many1)

many2.setMany1s(List of many1s)
saveOrUpdate(many2)

without giving errors half of the time or having to think
of single settings which in half of their combinations do not work
(I am speaking of the combination of lazy and cascade)

b) and in case of a binding object

many1.getBindings.clear();
many1.getBindings.add(list of bindings);
saveOrUpdate(many1);

in case of b) you get errors
if you do that if you have non lazy bindings
if you do not delete the bindings and do a flush can clean with a save before in between etc...
and evn
if you have a dedicated surrogate and the bindings
are totally new objects

only three cases I can see really work
a) iterating over the many1.getBindings by hand and to the readjustment
on an object to object base

b) having dedicated surrogates in the binding table

c) doing a delete on the binding table and having set lazy to true

d) resolve it by blank sql

in any other declarative way things will fail with cryptic errors.

there are often cases in legacy dbs where you cannot opt for b and c
and a is very error prone and really should be resolved on a db level.

and d) should be avoided if possible.

To sum it up
the problem is, there are too many options on how you are able to declare such a relational binding, and 80% of those options fail in the worst case (which is writing)
and no real helper class to ease things.

Declaring that advanced mapping problems does not help either, because I have yet to see a db more than a simple blog, where such constructs do not exist :-(