I am using Hibernate and POJOs within JBoss and detached objects on the client. One part of my object model has particular problems with that. It consists basically of 3 classes: a flow has a collection of vertices, and the vertices are connected by edges, i.e. each edge has a source and a sink vertex, while each vertex has a collection of source and sink edges. All 3 collections have cascase="all". Does that make sense so far?

I ran into two major problems so far:

First I tried to add 2 vertices and to an existing flow, and those vertices are connected by a single edge. Hibernate gave me an exception upon saving the edge because its sink vertex was transient. With the debugger I found out that the source vertex and the edge had been assigned primary keys while the sink vertex still had the unsaved value of -1. I was able to resolve the issue by setting cascade="none" on all 3 collections and writing some code that calls Session.saveOrUpdate() first on all vertices and then on the edges. However, I have to conclude that Hibernate has a problem persisting more complex object graphs at least for detached objects.

Then I tried to remove the edge from the graph. I tried to use cascade="delete" which just set references to null, so I wrote more special code to automatically call Session.delete(). I ended up using PersistentCollection.getDeletes(Type) to figure out what was deleted. Not very clean or idiomatic, but at least I got the information, and with cascades not working I didn't know what else to do. But then another problem came up: before deleting it, Hibernate tried to update the edge by setting the source vertex to null. This is a mandatory field, so I got a JDBCException. Making the field nulluable fixed the problem, but now the database doesn't enforce data integrity any more.

So I have some questions:
1. Is there a way to make Hibernate persist a complex object graph of detached objects?
2. Is is possible for Hibernate to detect when a detached object has been deleted and then just delete it? I thought that maybe cascade="all-delete-orphans" might do that, but XDoclet couldn't even generate that.
3. Is there a way to prevent the SQL update before the delete so that I can at least have data integrity?

1. yes, but assigned generator has drawbacks. basically detached objects use the saveOrUpdate() method. Read documentations on that subject

2. all-delete-orphan remove an object that has been unlinked to it's parent. delete will delete sub objects if the master object is deleted (session.delete())

3. Yes the not-null attribute is used

1. What do you mean by assigned generator? I am using generator-class="native" everywhere. And I also use saveOrUpdate() all the time. I think the issue is that Hibernate traverses the object graph in a certain order (depth-first) which lets it encounter unsaved objects when it doesn't expect it. Here is the exception I am getting:
net.sf.hibernate.PropertyValueException: not-null property references a null or transient value: com.ichg.capsela.domain.component.flow.ControlEdge.sinkVertex

This happens in the saveOrUpdate() of the edge, and the source vertex has already been saved, but the sink vertex still has the unsaved-value in the primary key.
By now I am convinced that this is a bug in the handling of detached objects.

2. I didn't use cascade="all-delete-orphan" because cascade="all" already breaks. Instead I implemented my own cascading logic, but that breaks because Hibernate tries to update a not-null field.

3. I had not-null="true" as my XDoclet tag and used the ant schemaexport to generate the database. But Hibernate still tried to set the field to null, even though I just called Session.delete() on the edge. We don't have this problem in a similar situation when we don't use detached objects.

I think I have done everything right and can consitently reproduce the problems, so my conclusion is that the problem is with Hibernate. I would be happy to give you my source so you can see for yourself (it is a small prototype with about 20 classes), just tell me if you want to do that.

Actually I got the deletion to work properly by adding inverse="true".
But I still maintain that Hibernate does not deal with detached objects properly.

You know, this kind of arrogant attitude:

"I can't make it work, so Hibernate must have a bug (even though 5000 other people are using this functionality and it works just fine for them)"

is really breathtaking and insulting to the people who have put so much hard work into developing this software.

Please show some humility or son't post here.

TIA.

P.S. LOL - I have never yet seen a bug that could not be reproduced in a simple model with two or three persistent classes. Has it occurred to you that if you simplified your own code, it might be easier to find your own bugs?

Gavin, you don't have to shout at me. I didn't mean to be arrogant and I do appreciate the work done by the Hibernate people, especially all the help on this forum. I will do as you said and try to reproduce the problem with a minimal set of classes. If the problem still occurs, what should I do with the test case? Post it on the forum or send an email to someone?

If you *really* think you have found a bug, you should submit the code to JIRA. But it should be a /very/ simple main() method.

You will be happy to know I had no problems reproducing the issue with a minimal set of classes, see HB-675 on JIRA.

I have looked at your issue and it is due to an error in your mapping.