-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: Polymorphic associations mapped lazily
PostPosted: Wed May 17, 2006 8:28 am 
Newbie

Joined: Wed May 17, 2006 8:26 am
Posts: 8
Location: Amsterdam
In Secion 6.4.1 of "Hibernate in action" the authors speak about some nuances of polymorphic many-to-one associations noting along, the way, that when such associations are mapped lazily there are limitations on the use of casting due to the use of proxies:

.. if BillingDetails was mapped with lazy="true", Hibernate would proxy the billingDetails association. In this case, we wouldn’t be able to perform a typecast to the concrete class CreditCard at runtime, and even the instanceof operator would behave strangely:
User user = (User) session.get(User.class, uid);
BillingDetails bd = user.getBillingDetails();
System.out.println( bd instanceof CreditCard ); // prints "false"
CreditCard cc = (CreditCard) bd; // ClassCastException!


Then they propose a way of dealing with this isse, which is based on knowing the expected runtime type:

User user = (User) session.get(User.class, uid);
BillingDetails bd = user.getBillingDetails();
// Get a proxy of the subclass, doesn't hit the database
// The below code assumes the knowledge of the expected
// runtime type of the bd instance.
CreditCard cc = (CreditCard) session.load( CreditCard.class, bd.getId() );
expiryDate = cc.getExpiryDate();

What they don't explain is how to dynamically figure out the runtime type of a given BillingDetails object. Consider this code:

User user = (User) session.get(User.class, uid);
BillingDetails bd = user.getBillingDetails();
// Suppose I don't know what dynamic type of the bd POJO is.
// Depending on the runtime type, I'd like to use different execution paths:
if (bd instanceof CreditCard) {
// process bd as a credit card;
}
else if (bd instanceof BankAccount) {
// process bd as a bank account;
}

Does Hibernate support this usage scenario for lazy associations?

Thanks in advance,
Andrei.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 17, 2006 9:13 am 
Expert
Expert

Joined: Tue Apr 25, 2006 12:04 pm
Posts: 260
have you tried lazy="no-proxy" on many-to-one element


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 17, 2006 11:01 am 
Newbie

Joined: Wed May 17, 2006 8:26 am
Posts: 8
Location: Amsterdam
bkmr_77 wrote:
have you tried lazy="no-proxy" on many-to-one element


Then it will work, thank you very much! In my situation, however I also need to find a way for it to work for polymorphic collections and the documentation on no-proxy says it cannot be used for collection-valued associations.


Top
 Profile  
 
 Post subject: lazy="no-proxy" doesnt work for me
PostPosted: Tue Oct 10, 2006 11:22 am 
Newbie

Joined: Wed Mar 15, 2006 5:37 pm
Posts: 3
I am having the same problem. I have a polymophic many-to-one association that I am trying to lazy-load and an instance of the base class
is always loaded. I am using joined-subclass in the polymorphic class. Using lazy="false" and/or fetch="join" returns the correct subclass, but lazy="true" and lazy="no-proxy" do not. What's interesting is if I turn on debug level logging hibernate says thats its hydrated an instance of the correct class. Am I doing something wrong? Does anyone know if these same problems occur with lazy-loaded polymorphic collections?


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.