In order to truly understand the inverse attribute in NHibernate, you need to first look at your relationship from the database table point of view and how your domain objects maps into their respective tables. It comes down to determining who is the owner of the relationship association between the parent and child objects.
Suppose you have ParentTable (parentId PK, parentcol1, parentcol2) and ChildTable(childid PK, parentid FK, childcol1, childcol2). In a one-to-many relationship, you will have one parent and many children. The ChildTable has a primary key and foreign key. The foreign key is a reference to the primary key in the ParentTable. If you look at the ChildTable, you will notice that the ChildTable stores extra information about a row in the ParentTable via the ChildTable's parentId foreign key. Using this perspective, the "child" owns (knows about) the relationship it has with its parent row. So, the child will be the owner of the relationship in this one-to-many relationship.
Where does inverse come in? Well, from the Parent's perspective, since the parent doesn't own the relationship it is considered the "inverse" of the relationship. Below is some additional information I pulled down an edited from IBM's websphere pages:
The entity declaring the many-to-one relationship is the child object (or owner of the relationship), as its table has the foreign key, while the object that is referenced by the entity declaring the many-to-one relationship is the parent object. Since its table doesn't have the foreign key, it is the non-owner, or inverse of the relationship.
In Hibernate, many-to-one relationship maps as follows:
- Use many-to-one element in the child class.
- Define the primary key in the parent class.
A one-to-many relationship defines a reference to a collection of objects. It is the most common kind of relationship that you will find in object models due to the fact that use cases typically require traversal from the parent object to its children, but may or may not require traversal from the child back to its parent; which means a unidirectional one-to-many relationship will suffice in most cases.
The entity declaring the one-to-many relationship is the parent object (and is the non-owner). The table for this entity defines the primary key, but it does not have the foreign key -- that is in the child.
In Hibernate, the mapping of one-to-many relationships is generally done by adding a column to the child table for the foreign key, but the details of the mapping differs depending on whether it is a unidirectional or a bidirectional one-to-many relationship.
In the unidirectional case, the foreign key column in the child table doesn't map to a property in the child object; it is in the data model, but not the object model. Since it is unidirectional there is just a property in the parent object [that contains a collection of children];
not the child [the child object does not contain any information back to the parent]. In addition, the foreign key column [in the child table] has to be defined as nullable because Hibernate will first insert the child row (with a NULL foreign key) and then update it [the inserted row] later [with the parent's primary key].
In the bidirectional case, the object-relational mapping is better because there is a property in the child object for the foreign key column, and that column doesn't have to be nullable in the database. But the resulting object model has cyclic dependencies and tighter coupling between the objects, and requires additional programming to set both sides of the relationship.
As you can see, there are several tradeoffs to consider with regard to the definition of one-to-many relationships, but using unidirectional relationships is generally recommended unless there are use cases that indicate the need for navigation in both directions.
In Hibernate, one-to-many (unidirectional) relationships map as follows:
- Use the set, bag, or list with one-to-many sub-element in parent class.
- Create a foreign key in the table representing the child class if the relationship is unidirectional; otherwise, use the many-to-one relationship for a bidirectional relationship.
There are some additional features that are often used in the definition of one-to-many relationships[...]:
In Hibernate, you might encounter the inverse="true" attribute being used in the definition of a bidirectional relationship. If so, don't worry, because this feature is equivalent to ... the non-owner of the relationship whose table doesn't have the foreign key. Similarly, the Hibernate inverse="false" attribute is equivalent to the ... owner of the relationship whose table has the foreign key.
In general, these notions align, except for the case where someone defines a Hibernate mapping with inverse="true" set on the many-to-one side of a bidirectional relationship. If you find such a mapping, you should change it ..., as it is not a best practice in Hibernate and does not generate optimal SQL. For instance, if the many-to-one side is set to inverse="true" then every time you create a child, Hibernate will execute two SQL statements, one to create the child and one to update the child with the foreign key of the parent. Changing it to inverse="false" on the many-to-one side and setting inverse="true" on the one-to-many side will fix that oversight ...
A many-to-many relationship defines a reference to a collection of objects through a mapping table. Many-to-many relationships are not all that common in an object model, but they will generally be bidirectional.
Like the other bidirectional relationships, there is an owning and a non-owning side. In this case, the owning side has the mapping table, instead of the foreign key. Either side can be designated as the owning side; it doesn't matter which side you pick.
In Hibernate, many-to-many relationship maps as follows:
- The non-owner uses the collections (set, bag, or list) element with the inverse="true" attribute, the table attribute, the key sub-element, and the many-to-many sub-element.
- The owner of the relationship uses the collections (set, bag, or list) element with the table attribute, the key sub-element, and the many-to-many sub-element.