For the past week or so I have been using Hibernate 3.0 and MySQL 4.0.18 to persist a graph of objects. The graph is sumarized as follows:



Code goes along these lines:

Here is a section of the Parent.hbm.xml file:


Here is a section of the Node.hbm.xml file:

Here is a section of the Link.hbm.xml file:




When I try to persist this graph using session.save(aParent) I get the following exception:



After some Hibernate debugging it seems that when Hibernate tries to save the only Link object I have in my test graph it nullifies either the source or target Node (it seems to vary for each debugging session). Since both Link.sourceNode and Link.targetNode cannot be null, the exception is thown.

Some questions:
(1) Since I would expect an ORM implementation to take care of graphs, what am I doing wrong here?
(2) Shouldnt Hibernate first reach all dependent object and then start saving them?
(3) If this is a bug, is there a work around?

Any help would be greatly appreciated!

thanks,

-- yuri

Read the rules before posting!
http://www.hibernate.org/ForumMailingli ... AskForHelp

Hibernate version:

Mapping documents:

Code between sessionFactory.openSession() and session.close():

Full stack trace of any exception that occurs:

Name and version of the database you are using:

The generated SQL (show_sql=true):

Debug level Hibernate log excerpt:

This is almost certainly a cascade problem. I find that when you persist an object graph with cycles in it, you need the save-update cascades going in the "opposite" directions (e.g. on many-to-one elements) back up to the root entity you told it to save. It seems to depend on how Hibernate walks the object graph during cascades. You can turn up the log level on the Cascades class to see this.

In my view, this is one of the few frustrating things about working with Hibernate and an area that could stand some improvement. As a developer, I shouldn't have to worry so much about how it will walk the object graph. For example, given a graph like this:

If the relations from A->B and A->C declare cascade="all", and I try to save A, it ought to work. But it doesn't unless you also have cascade="all" on the inverse relations.

Yes, that confirms what I saw debugging Hibernate. The cascading follows the property values in order and depth first. In your grapth Hibernate saves A, B and then reaches C, which is not yet saved and is assumed to be a transient object, which causes its nullification.

I added cascade="all" to the many-to-one relations on Link and it worked fine.

I dont yet fully understand the implications of the cascade attribute, but I do agree in principle that having or not having a cycle should not change the behavior of Hibernate.

Thanks for the help!

-- yuri

This not even remotely true. The overwhelmingly common case is that bidirectional cascade does not make semantic sense, from the point of view of the lifecycle of the data.

Should an Item become persistent when we make a new Bid persistent? Should a Group become persistent when we make a new User persistent? Of course not. From a business point of view, relationships have defined lifecycles, and cascade create happens in one direction only.

Even if, in the uncommon case, bidirectional cascade does make sense, it is almost certainly not true that the actual cascade setting would be the same on each side. (One side might be "all", whereas the other would be "save-update, persist, lock", for example.

And how in hell could this be "frustrating", when as you have correctly observed, enabling this almost-always-nonsensical bidirectional cascade is as simple as setting an attribute on the other side of the relationship??

I agree with you! I don't want to put a save-update cascade rule on the inverse relations. But this is the only way I've been able to do "one-call" saves of object graphs containing cycles, like the example I mentioned in my reply. If there is a better way to accomplish this, I'm all ears.



It's frustrating to debug. It makes it more difficult to save (or delete) complex graphs of objects using cascades because you have to figure out where there is a cycle that's causing a problem.

There's no reason to become defensive. Hibernate is a great tool. In my company, I'm its biggest fan. But it's not perfect. It seems like any time someone on this forum suggests otherwise, the Hibernate team takes it as a personal affront.

Gavin,
I actually have one side of my bidirectional cascade set to cascade="all" and the other side set to cascade="all-delete-orphan". Following from your paragraph above this is wrong, no? What is the implication of setting both sides to "all"?