Design your Entity classes accordingly so that you can use your getter methods to get values.

Consider the account-customer example in the lecture notes. Suppose account-customer is many-to-many and we use bidirectional association.

In DAO I just need a simple getAccountById() in AccountDao and a simple getCustomerById() in CustomerDao.

In application code (like controllers and test cases), if I'm given a accountId, I can do accountDao.getAccountById(accountId).getOwners(), and if I'm given a customerId, I can do customerDao.getCustomerById(customerId).getAccounts(). Note that ORM automatically generates queries to retrieve the collection data so you don't need to it yourself.
 

lmann2 wrote:

I have a similar question, but I think it's slightly different.  I'm having a heck of time trying to model a many-to-many relationship (the result I want is table with a composite PK of two separate model classes).  Without giving away two much away about my model I'm trying write in Hibernate something that models something like a Book-Book_Author-Author relationship.  

Or rather the scenario that I need to handle a many-to-many association but also hold some additional property on the association.

The only solution I can find is a a common model that's floating around the internet that involves a embbeded PK table for the composite table and hashcode.  

Which tells that maybe it's just bad design??  Why doesn't hibernate have some easy annotation to handle something that seems like a very common design?

A common design floating around the internet may not be a good design ...

The fundamental problem is that classes and tables are quite different things. There are even significant differences between classes and ER models even though ER is supposed to be OO. For example, multi-way relationship and relationship with attributes (which seems to be what you want) simply don't exist in classes.

An easy way to deal with relationship with attributes is to replace it with an entity set (i.e. a class). For example, consider the order relationship between Customer and Book: a customer can order many books and a book can be ordered by many customers, so it's many-to-many, but what if you want to associate additional attributes with an order such as order date and ship date? Well, just make Order an entity set (i.e. class) which can have as many attributes as you want, and then instead of one many-to-many relationship, you'll have two many-to-one relationships Order-Author and Order-Book.

Well, just make Order an entity set (i.e. class) which can have as many attributes as you want, and then instead of one many-to-many relationship, you'll have two many-to-one relationships Order-Author and Order-Book.

Which is kinda what I did I have new class with a Order-Author and Order-Book relationship, but the @Entity annotation requires that I choose just one field/colmun (marked by @Id) to be the PK.  I created a new idea in the third class to act as the PK and kinda get the result I want, but my goal is really to generate a composite key of the two id fields of Book and Author.  If I want to mark two fields with @Id I'm asked to: "This class has a composite primary key. It must use an ID class."

Beyond that I think that implementing the call in the DAO might be difficult...my current notes are something like:

can you do this in hibernate?
student.studentCheckpoints().getCheckpoints(); 

cysun wrote:

I think Hibernate/JPA supports composite key, but why go through that trouble? Just create an Integer/Long field as the primary key and create a unique constraint for the columns that constitute the composite key.

Perfect!