Folks,

I'm having conceptual problems with trying to model a particular relationship. What I need is a one-to-one, parent-child relationship. The Parent and Child tables have a common primary key, with a constraint from the Child table to the Parent.

Currently, I'm modelling them as a primary-key-association one-to-one mapping as described in section 5.1.11 of the Hibernate docs, but this gives dreadful performance - querying for Parent objects triggers a torrent of select statements for the Child objects.

I've been back and forth on this problem using various alternatives, but none seem to model what I'm after. The example in Chapter 16, for instance, deals with a collection of child objects, rather than a one-to-one.

One solution is to give the Child table it's own primary key sequence, and model the relationshop as a many-to-one, but I'd rather keep the shared-primary-key shcema if possible.

Any thoughts?

Set the classes to lazy="true".

I'm not sure how that helps. Firstly, I want the initial select on parent to grab all the information for Parent and Child in one go using an outer-join. Secondly, iI tried adding lazy="true" to Parent and Child, but I'm still getting multiple selects issued when I query from parent;

What is "when I query from parent"?

Sorry, that was a bit amniguous :)

I mean when I do something like session.find("from Parent")

Thats because HQL ignores any mapping metadata fetching strategies, for a good reason: You can define a runtime fetching strategy by using the "fetch" keyword, or with Criteria, a FetchMode.

Ah, OK, that makes sense.

So how about this lazy attribute? Even after I added lazy="true" to the <class> tags of Parent and Child, I'm still getting the mutltiple select when I run the query. Shouldn't this be a property on the <one-to-one_ mapping, rather than of the class itself?

Ahem, read again what I said. You will of course get immediate additional selects, since HQL ignores whatever you specify as a fetching strategy in your mappings. And yes, it would be nice if the lazy="true" was on the association mappings, not the class, but this is not how it is implemented.

But lazy="true" is a fetching strategy, is it not? When I add this to a collection mapping, it prevents additional selects to fetch the collection, but this is not the case for <one-to-one> associations.

So while I can use the FETCH clause to speed things up, how can I make the one-to-one association a lazy one?

Thanks for your patience :)

I'm at a loss here. You have to think about "default strategies" and "runtime strategies". What you define in mapping metadata is the default, you can override/ignore this with HQL or Criteria queries at runtime. The default fetching strategies are used whenever you a) load an object by id with get() or load() or b) navigate an object graph.

Yeah, we seem to be tying ourselves in knots here. Allow me to return to my original problem.

I have a better idea of what's going on now, but I still need a way to alter the mapping so that "select from Parent" does not issue the additional select for Child, but rather fetches Child lazily. This is what I see with a <set> mapping, and I'd like something similar for <one-to-one>.

My point is that you can't alter the mapping in any way to get this with a "from Foo" query. HQL ignores any fetching strategy in your mapping. You know, why don't you try a simple "from Foo join fetch foo.bar" and look at the generated SQL. It will not change, whatever mapping fetching strategy you try. Then try loading Foo by id with get() and load() and try the different mapping attributes.

Erk, I see what you mean.

So how come I can influence the behaviour of "select from Foo" when Foo contains a Set (by adding lazy), but I can't influence it when I have a <one-to-one>? Why is the default fetch behaviour different?

For example, <set name="bar" lazy="true"> will prevent a multiple select, but there seems to be no equivalent for <one-to-one>

I understand the behaviour of the query now, I just don't understand this apparent inconsistency. Are collections just a special case?

I just read this:

http://www.hibernate.org/162.html

Bugger.

Ah well, not to worry. At least I understand this a bit better now.

Thanks for your help.