I've been going the rounds with this one myself. (Search for "Bidirectional lists - for the record" in the forum for my unintelligible gibberish conversation with the gurus!)
Basically it comes down to a short answer and a long answer. You're better off with the short one, which is: "Just because."
The long answer has to do with two issues.
Issue 1 is easy to understand. Indexed lists are inherently non-inverse because the ordering is managed on the primary key side (the list). Marking a collection as "inverse=true" means that you're going to manage the relationship from the child (many) side. See the conflict? The relationship can't be managed from both ends. It's just the way Hibernate is designed.
Issue 2 is more difficult: You can't have a many-to-one relationship back to the parent in an indexed list or you'll have problems. For this one, I'll leave you to your own devices because I still haven't figured this one out yet. It has to do with object graph traversal being impossible for this scenario. Dig into the source for more info.
As a final gotcha for this whole thing, for indexed lists to work properly you must use a foreign-key constraint that is nullable. For many (myself included) this is somewhat unappealing because of the possiblity of orphaned rows. The reason the FK has to be nullable is that Hibernate takes the relationship semantics very litterally. When you move an item in the list, you first take it out of the list and then move it to a new position. This results in a double update - one to remove the relationship (set the FK to null) and the other to add it back into the list. (Oh, and one more bulk update to resequence).
So, there you have it. As I said before, the best answer of all is "just because." It's the way it is.
That being said, there is an interesting work around that exists:
http://www.hibernate.org/193.html
Login
FAQ
Search
