inverse="true" says that the *other side* "owns" the association. The documentation is correct; just a little misleading (you *are* telling Hibernate which side owns the association: the other side!).

Btw, that quote you pasted *did not* come from the doc link you pasted; maybe check out the the newer docs as they seem much clearer.

Steve,

Thanks for your answer but please avoid saying things like "that quote you pasted *did not* come".

Search the page for "We use the inverse attribute." to find the place where I took the quote from (it's directly below that sentence).

Now, you've claimed something which is not true. Please use "I couldn't find your quote. Where is it?" instead. This way, no side will have hurt feelings. :-)

Back to "inverse".

I do understand what inverse does. I've been using TopLink and there, you must also tell the ORM on which side of an association it should run the updates if there is more than one.

I first had a look in chapter 1 but because those examples seemed to match my problem less, I took chapter 21 (which contains an explicit and simple parent/child relation) as a basis for this discussion.

Right now, I think that there might be a bug in this chapter 21.

Let's see if we agree:

We have a parent-child relation, which means the child object has a pointer to the parent and the parent has a collection with children.

Now, we must tell Hibernate which side "drives" the relation: Do children attach to parents or do parents add children to themselves?

In the first case, I would expect the inverse on the children collection (relation is driven by parent pointer/parent_id field).

In the second case, I would expect the inverse on the parent field because we want updates in the DB when the collection changes. Just setting a parent pointer is not really "adding" the child to the parent.

The example in chapter 21 specifically adds the inverse to the children collection so it's not driving the relation which matches my expectations and the first case as described above.

In my code example (see HHH-1894), I'm doing the same, but I also set how to cascade (as described in chapter 21.3). My code is an unmodified copy from that chapter!

Now you say, I'm wrong because I'm using inverse in the wrong way or wrong place.

That doesn't make sense for me. From what I can see, I'm doing exactly what you can find in chapter 21 of the current, most up-to-date Hibernate documentation.

Regards,

In a bidirectional, many-to-one association the collection end is *always* logically the inverse end...

No, it is not unmodified code from that chapter. Where in 21.3 does it show moving children between parents? Err, sorry : "I don't believe your code sample is an unmodified version of the code shown in the section of the documentation you reference. Would kindly point me to the appropriate points within the documentation where I might reference the particular 'unmodified' code fragments you mention?" Yes, I am a parent :)

I'm referring to the mapping itself. When the documentation gives an example for a parent-child-relationship, I expect reparent to work.

That is what caused the discussion: The last example in 21.3 reads:


This is exactly what I used in my code and it didn't work, so I suspected a bug in Hibernate when I couldn't find a test case in the sources.

Just to recap: With this code, I could insert, add, edit children and move them around in one collection. It only fails when one tries to move a child from one collection to the other.

I suggest that you mention this is a shortcoming of delete-orphan in 21.3 along with an example how to deal with it. How about this:

Unfortunately, Hibernate can become confused when you try to move a child from one parent to the other when you use all-delete-orphan. The reason behind is that Hibernate sees this as two operations: First, the child is deleted from the first collection which translates into a DELETE sent to the database because the child is now an orphan (it's no longer connected to anyone).

Next, the same child is added to a different collection which means the DELETE must be relaced with an UPDATE. But Hibernate cannot know that these two operations are related, so it cannot do this. Instead, it sees that an object which is marked for deletion, suddenly appears somewhere else, so it throws an ObjectDeletedException.

If you need reparenting of children, you have to use cascade="all". When you have to delete children, you must do so manually as described above.

Regards,

Note: if it would help, I could extend the code from HHH-1894 into a full-blown example for implementing parent-child relations (create new nodes, add children, remove children, move them around, etc).

Any comments?

...

Contrary to what some people here indicate, this problem is a real one (e.g. someone asks the same question for NHibernate 1.0.2 - http://forum.hibernate.org/viewtopic.php?p=2331850 -, and we also have it).

If some of the posters knew a little more about composition semantics (e.g. in UML), they would understand that moving a "value object" (a composed object) from one parent to another is definitely useful and makes sense and is the standard semantics; however, (N)Hibernate being a mere tool which is programmed as it is, we probably will have to accept that it's semantics is as it is ...

But, essentially, you'd probably have to throw Hibernate out to solve the problem correctly (I have written a complete OR mapping myself and know that some assumptions one makes at the beginning are so deep-grained in the machinery that they are never going to be corrected later-on - their negative consequences are simply "defined away", and the users are defined to be the culprits; I've been guilty of the same myself).

Regards
Harald

I wouldn't say that Hibernate is so broken that it can't be fixed.

I've just bought the new book from C. Bauer ("Java Persistance with Hibernate"). In there, they go to great lengths to explain parent/child relations and what the attributes means, etc.

I would have had less problems if such an explanation would have been available one year ago. Alas, the "move child between parents" is not handled in the example. I'll have to verify my code against the new documentation to see if it has been fixed.

Okay, it took some time but I could take another try with my code today. Right now, I'm using Hibernate 3.2.3.ga and Annotations 3.3.0.ga and with this code, the parent/child tree works (including reparenting of nodes):



Notes: I'm keeping the children in a sorted list, the POS column is an integer. Because I'm lazy, I don't allow to move children by setting their position.

In the DB, "parent" is a column with the same type as the ID of the rows in the table (BIGINT in my case). Since this is a tree, "parent" can be null (= root nodes)!

When I change the parent of a child which is already attached to a different node, I see a single UPDATE line in the log.

PS: With quite a bit of satisfaction, I'd like to add that my old code also works unmodified with Hibernate 3.2.3.ga.

I'll leave it as an exercise for the reader to figure out what "completely broken" means, now.

Ha ha, classic. And if you're a newbie that needs to be spoon fed I'd hate to see how they treat other people with even less experience.