OnoToOne Join Problem

redijedi · **Joined:** Sun Mar 06, 2005 3:18 pm **Posts:** 7

I cannot seem to get the desired affect when querying for users in my application. Consider that I have an object User that has a property Credentials. I am using separate objects because Credentials may be possessed by other objects than Users. So, I do not want any user specific data in the Credentials object/schema.

I use the following annotations in my User object:

Code:

@OneToOne(cascade = CascadeType.ALL)
@JoinColumn(name = "cred_pk", referencedColumnName="cred_id")
public Credentials getCredentials() {
   return credentials;
}

Credentials does not have any mapping info other than the requisite @Id and @Column properties.

The behavior occurs when I get the list of users using the following:

Code:

Session session = HibernateUtil.getCurrentSession();
session.beginTransaction();
Query q = session.createQuery("from User as user");
List<User> l = q.list();
session.getTransaction().commit();

I see in the hql output that it selects from users once as desired. However, rather than joining to credentials (as I'd suspect) it performs n separate select statements per each user returned. Clearly, this is inefficient.

How can I ensure that a single select is issued to return all of the data I am looking for?

Thanks

LaLiLuna · **Posted:** Sat May 06, 2006 6:32 pm

The fetch strategie is missing.

Best Regards

Sebastian

redijedi · **Joined:** Sun Mar 06, 2005 3:18 pm **Posts:** 7

I changed the @OneToOne to

Code:

@OneToOne(cascade = CascadeType.ALL, fetch=FetchType.EAGER)

It still exhibits the behavior described.

redijedi · **Joined:** Sun Mar 06, 2005 3:18 pm **Posts:** 7

So, I've changed my hql to:

Code:

"from User as user inner join user.credentials as credentials"

Now I get the data back in one query, but two objects. I have to loop over the entire result set and cast Object[0] and [1] to User and Credentials, respectively. Then I have to add the creds to my user and place it in a new list. Essentially, I've traded a sql inefficiency for a code inefficiency. I suppose that's better if volume's high, but if the result set is large I'll be in for a dog of a page load/heap allocation. Seems I can't win here.