text: > with LineItems. And, if I am having a problem with eagerly loading the
  > lineitems, then we probably have a problem with OpenJPA. Is that your
  > thinking?
  Yes. It might just be a configuration issue; I would start by manually
  programmatically configuring the FetchPlan to make sure that the right
  graph is being specified. One easy way to test that OpenJPA has the
  same interpretation of the FetchPlan as you do is to do a
  StateManager.isLoaded() check on all the requisite fields after the
  query execution has happened; you might see multiple SQL statements to
  materialize the fetch plan, but that is "just" an implementation
  detail. Once you're sure that OpenJPA is in fact loading all the
  configured data by the time the query is finished executing, then we
  can figure out where the inefficiencies lay.
  -Patrick
  On 8/27/07, Kevin Sutter <kwsutter@gmail.com> wrote:
  > Patrick,
  > If I am interpretting your response correctly, I should not be running into
  > the documented restriction with the scenario as described. So, if I specify
  > EAGER fetching on the OneToMany with lineitems, I should be able to get this
  > collection loaded if all that I do is a find on a Customer? Given that
  > Customer has an EAGER OneToOne with Order and Order has the EAGER OneToMany
  > with LineItems. And, if I am having a problem with eagerly loading the
  > lineitems, then we probably have a problem with OpenJPA. Is that your
  > thinking?
  >
  > Thanks,
  > Kevin
  >
  > On 8/27/07, Patrick Linskey <plinskey@gmail.com> wrote:
  > >
  > > I do not think that you should be running into the limitation, given
  > > your description. At least, the reason that the limitation is there
  > > should not have any theoretical impact on that model.
  > >
  > > The conceptual limitation is that every time we eagerly load a to-many
  > > relation (true eager, not a parallel select), we significantly
  > > increase the number of rows returned by the query. Of course, in
  > > particular cases, this might not be an issue for sufficiently
  > > low-cardinality relations. However, based on the fact that it's
  > > typically not desirable to do multiple to-many joins, OpenJPA makes
  > > the assumption that it's never beneficial. The upshot is that the
  > > logic to handle weeding out duplicate records from a result set that
  > > has an eager to-many only works for a single to-many relation.
  > >
  > > So, the case that would not work would be if your Order class had a
  > > to-many to LineItem and also a to-many to Approval, and you wanted to
  > > eagerly fetch both relations.
  > >
  > > -Patrick
  > >
  > > On 8/23/07, Kevin Sutter <kwsutter@gmail.com> wrote:
  > > > Hi Guys,
  > > > Can someone help me interpret a limitation specified in section 7.2:
  > > >
  > > >
  > > > - Once OpenJPA eager-joins into a class, it cannot issue any further
  > > > eager to-many joins or parallel selects from that class in the same
  > > query.
  > > > To-one joins, however, can recurse to any level.
  > > >
  > > > So, if I have the following code, am I hitting this limitation?
  > > >
  > > > public abstract class AbstractCustomer implements Serializable {
  > > >
  > > > ...
  > > > @OneToOne(fetch = FetchType.EAGER)
  > > > @JoinColumns({@JoinColumn(name="OPEN_ORDER", referencedColumnName =
  > > > "ORDER_ID")})
  > > > protected Order openOrder;
  > > >
  > > >
  > > > public class Order implements Serializable {
  > > >
  > > > ...
  > > >
  > > > @OneToMany(fetch=FetchType.LAZY)
  > > > @ElementJoinColumn(name="ORDER_ID",referencedColumnName="ORDER_ID")
  > > > protected Set<LineItem> lineitems;
  > > >
  > > >
  > > > In order to load all LineItems Eagerly, I have to start from Order (vs
  > > > starting from Customer).
  > > >
  > > > If I do an em.find() on Customer. Even if I specify Eager from Order to
  > > > LineItems, it will not load the LineItems Eagerly. Only if I do an
  > > > em.findon the Order will I get the Join because LineItems is a
  > > > collection.
  > > >
  > > > Have I interpretted the limitation correctly? And, if so, can somebody
  > > > provide some background on this limitation and what it would take to
  > > remove
  > > > it? I'm still not 100% comfortable with this area of the code... :-)
  > > >
  > > > Thanks!
  > > > Kevin
  > > >
  > >
  > >
  > > --
  > > Patrick Linskey
  > > 202 669 5907
  > >
  >
  --
  Patrick Linskey
  202 669 5907