Question on Polymorphism

ellisyu · **Joined:** Tue Oct 02, 2007 3:49 am **Posts:** 17

Dear All,

I've 2 inheritance classes LibraryBook and PurchasedBook and both are extended from a base class MyBook. The inheritance strategy is using "TABLE_PER_CLASS". And now, I'm going to lend my book to other. Thus I'm going to build a class "BorrowOut" to keep track the record.

In this class,

Code:

@Entity
@Table(name = "borrow_out")
public class BorrowOut extends ModelBase implements Serializable {
   @Id
   private String recordNbr = "";

   @ManyToOne(optional = true)
   @JoinColumn(name = "book_nbr")
   private MyBook borrowOutBook;

......

My question is when I check the instance of borrowOutBook, can it identify it's belong to LibraryBook or PurchasedBook? and if I cast it to its class after identify, is it possible to access its attribute? e.g in LibraryBook, there's a return date or borrow date that it didn't exist in PurchaseBook. or is it wise to use this inheritance strategy ?

Reason of I choosing "TABLE_PER_CLASS" is there's not many common fields in between LibraryBook and PurchasedBook. Only bookNbr and bookName are shared. And the @MappedSuperClass can't apply also in my situation. Does it make sense? I'm appreciate on any idea or advice. Thanks

Best Rdgs
Ellis

andydale · **Posted:** Thu Aug 14, 2008 3:44 am

Hi,

The TABLE_PER_CLASS inheritance strategy, uses SQL UNION to perform polymorphic queries, this could be an issue (i have ran into issues before).

Seems as you have mentioned that there is very common fields between the classes, I think SINGLE_TABLE can be ruled out as it will generate multiple null values per table row.

This leaves the 3rd option which is the JOINED strategy, for your given example would create 3 tables (1 for each class). The MyBook table would contain just the common attributes, the LibraryBook table would contain the class's specific attributes, and the PurchaseBook table would contain the class's specific attributes. The only downside of this approach is that it uses left outer joins to help in determining the type, which is probably not a problem with 2 subclasses but could soon become one if more subclasses are added.

If i had to chose a strategy I would probably go with JOINED as you only have 2 subclasses.

Cheers,

Andy

ellisyu · **Joined:** Tue Oct 02, 2007 3:49 am **Posts:** 17

Hi Andy,

Thanks for your help. But I still have some questions on this issue. How can I instantiate the MyBook instance to "LibraryBook" or "PurchaseBook"? I read a article mentioned I have to fetch it in eager mode. Otherwise, you can't instantiate it. Do I just simply set the fetch=FetchType.EAGER ? and any special thing I need to pay attention on? Thanks

Best Rdgs
Ellis

andydale · **Posted:** Thu Aug 14, 2008 2:11 pm

Hi,

To illustrate a simple query on the MyBook hierarchy.

Code:

Query q = mEntityManager.createQuery("from MyBook mb");

List<MyBook> res = q.getResultList();

for(MyBook b : res) {
   if(b instanceof LibraryBook) {
      LibraryBook libBook = (LibraryBook)b;
      
      // do stuff
   }
   else if(b instanceof PurchaseBook) {
      PurchaseBook pBook = (PurchaseBook)b;

      // do stuff
   }
}

This is only a simple example that queries the MyBook structure only, but it is very easy to change the query to something like this:

Code:

Query q = mEntityManager.createQuery("from BorrowOut b INNER JOIN FETCH b.borrowOutBook ob");

The above query joins the 2 entities, and eagerly fetchs the MyBook sturcture, you can then apply the same logic as in my first example.

I hope this helps, and the query should be independent from the inheritence strategy being used (it should work with all).

Cheers,

Andy