Greetings,

I have two classes: Assembly and Component.

An Assembly is a collection of Components. This suggests a one-to-many mapping.

The order of Components in an Assembly is important. This suggests that I want a list collection.

I want to be able to ask an Assembly for its Components, but I don't need to ask a Component what Assembly it belongs to. This suggests that I want a unidirectional mapping.

Chapter 7.2.3 says: "A unidirectional one-to-many association on a foreign key is a very unusual case, and is not really recommended."

This statement doesn't make any sense to me. A unidirectional one-to-many mapping doesn't strike me as unusual in any way. The suggested strategy is to add a join table, which seems to add an unnecessary join to every query. There is no suggestion as to what benefit there is to using a join table in this case, so I keep reading.

Chapter 7.4.1 says: "A bidirectional many-to-one association is the most common kind of association. (This is the standard parent/child relationship.)"

Assembly/Component, parent/child, not exactly, but I'll bite. I copy and paste the example, and season to taste (substituting Assembly for parent, Component for child, and list for set, and add a list index).

Now I'm getting a:

org.hibernate.HibernateException: null index column for collection: Assembly.components

This appears to be caused by the inverse="true" attribute on the list mapping. If I remove that attribute then the code appears to work. However, a careful examination of the SQL indicates that the INSERT statements that add records to the Components table ignore the list index field, and that subsequent UPDATE statements are needed to fix that. In HSQLDB, this is not a big problem, however when I deploy this, the index field in the Components table will not allow NULL values. After all, what good is a Component that is part of an Assembly, but not anywhere in particular.

Is there a better solution?

Peter-Frank Spierenburg

Its "unusual" because normally it is the many side of the relationship that is used to control the database updates.
When you have a mono-directional one-to-many, the updates must be controlled from the "one" side since the many side has no reference to its parent (hence different code is used).

I am guessing that the "not really recommended." clause is probably something to do with a "many" object with links to multiple parent classes as it seems to work fine in the simple case.


BTW I found this article useful too:

http://lizjason.com/blog/?p=7


PS Make sure you set not-null="true" on the key element.

Thanks. Great help.

The article you referenced was almost exactly the ticket. One minor detail confuses me tho'. On the 'one' side of the relationship, the mapping mentions cascade="all-delete-orphan". I had originally had cascade="all", which works fine. When I change it to "all-delete-orphan" I get the following exception:

"A collection with cascade="all-delete-orphan" was no longer referenced by the owning entity instance"

I suspect that it has to do with how I'm relying on Hibernate to persist the Components when I persist the Assembly. Should I persist the Components separately first and then persist the Assembly?

Peter.

I am assuming that you have defined the relationship as bi-directional.

Therefore the Assembly would "own" the Component, hence I don't think it is possible to persist the Component first you would either need to persist both at the same time or do the Assembly first.


With regard to the error I suspect that you are removing the Component from the Collection maintained by the Assembly, but you haven't set the reference from the Component to the Assembly to null.

Hence hibernate is traversing the link from the child to the parent, but then discovering that the child is not part of the parents collection.