Still learning here, got some questions. Reading Hibernate in action and I got a question about bidirectional associations. In the beginning in chapter 3, page 110, where it talks about the relationship of Item to Bid. There are many bids to one item. It talks about creating this bidirectional association.

It says by specifying the "inverse" property in reference to the item's Set of Bids we are effectively telling hibernate not to save changes made to this set so it doesn't double save. My understanding is of this is that changes will only be persisted when a bid specifies it's item. Not when an item adds a bid. However it then seems to contradict itself by suggesting using the cascade="save-update" in the same mapping where inverse is specified. It seems contradicting to use the cascade and inverse property in the same context, could someone explain this to me?

On this same note I believe I understand the concept of bidirectional associations. However, I am debating with myself whether it is really necessary to implement it in the domain model.
In a lot of cases I would be happy only having access to Bids through an Item and don't really ever need to access an Item from a bid. To me it seems like mapping all these bidirectional associations on both sides would result in a lot of extra sql calls and a performance hit. Am I correct?

Instead of actually mapping the Item class to a Bid through the item id couldn't I just set the Item Id field and not worry about loading the Item every time I want to see a bid? Is there kind of a best practices rule on this?

If I do this I assume I still need to do a bid.setItemId(.. before I say item.addBid(bid). If I say item.addBid(bid) and don't set the item id field what will happen when I persist the Item class?


Also on more question what is the difference in cascade value of an association between cascade="all" and cascade="all-delete-orphan"?

Cascade means cascading object state. Inverse controls the SQL statements. They are not related in any way.

You don't [i]have[/] to use bidirectional relations. It's just as you suggested: Decide whether you need them in your classes, and if not, leave that inverse stuff away. Hibernate's saving to the database won't be affected by this, i.e. it will save the objects and set the foreign key right, no matter whether the association is bidirectional or not.

Loading the associated objects together with an objects is a totally different matter. It is controlled by the lazy parameter -- see the docs.

Adding delete-orphan will delete the associated object if it's orphaned (not referenced by any object) any more.

I thought Cascade=all means it will save everything. But Inverse indicates that in a bi-directional mapping that the objects should be saved on the other end, in this case shouldn't cascade=all be on the other end?

Ok so only use them when you need them in the business side, i guess. That is awesome that it will automatically set the foreign key for you.

I am still a bit confused as to where you put the inverse attribute vs where you put the cascade attribute in a bi-directional association.





So "all" isn't really "all" it is all but delete-orppan?

The non-inverse side will be used for Hibernate to find out which changes to the association have been made. So they are for controlling the mapping of the association to the database (i.e. deciding which foreign key values to set).

The cascade has a quite different purpose. Provided that an association is already here, it controls which inserts, updates, or deletes are propagated from one object to other objects.

Btw, you should read the reference manual in addition to Hibernate in Action. While the book has more coverage of fundamentals, the ref manual goes into the details of each option e.g. of those mappings.