For the record, exactly why can't I have a bidirectional indexed list? I understand why it can't be inversely managed because of the sequence. I also know that someplace in the Wiki or FAQ there's some decent explanation, but I just can't seem to locate it! (A link to those documents would be helpful to me and anyone else who reads this in the future).

I've got several relationships that require a bidirectional reference back to the parent object but can't do it because you can't have a bidirectional indexed list.

Also, if someone could shed some light on why the foreign key of an indexed list has to be nullable, it would be appreciated. I know the mechanics - it deletes the relationship before cascading the delete to the child object. This seems incredibly inefficient. Is there some other reason for this?

Yes, I've read that one already (several times, actually). And yes, I'm capable of using the search and did use it. It still does not answer the question...

Why.


Why is this not a feature? Why does the foreign key have to be nullable? Isn't there a better way?

Because you cant find the state of all columns by navigating from the object.

Actually, its quite possible in HB3 <key not-null="true">, and the way we implement it is an ugly "search the entire session to find the parent object". yick. But it works, for people like you who find bidirectionality just so offensive.

(...shrugging off the "people like you" comment because I'm magnanimous, a really swell guy, and overwhelmingly thankful that Hibernate exists...)

Thanks for the answer to my inquiry.

So, to restate, "bidirectionality" in the sense you describe it implies that the entities involved can exist independent of each other. Truly the sematics of relational database tables do not reinforce the parent-child relationship without introducing the foreign key contstraint.

In my specific case, a parent object contains an indexed list of child objects. "Bidirectionality" is what I'm actually shooting for - navigation from the child back to the parent. It's not offensive in this case, it's actually desirable.

I can understand why the "inverse=true" challenge exists. Since the sequencing is managed by ordinal position in the list, trying to manage the relationship from the child while simultaneously managing the ordering from the parent would be tricky.

But, why is a many-to-one reference back to the parent difficult from an ordered list? If I can attempt to answer my own question, is it because the presence of the many-to-one is itself a relationship that implies the relationship will be managed from the child side? Does that mean that bidirectional relationships are inherently inverse by nature? If you create a bidirectional association,

As to the NULL-ABLE foreign key on the child object, I guess you're right, I am offended by that... since it allows orphaned rows. Is that a prerequeisite condition for "bidirectionallity?" I know it's there to support the resequencing by deleting the relationship, then reassociating it when the object's position moves... It all directly mirrors the actions taken on the collection - true semantics! Still, seems icky to have a nullable foreign key on a child table.

Amazing, I've not understood a single sentence :)

Mission accomplished. My response was as unintelligible as Gavin's! Hehe.

(Joking guys. You know we all love ya... )