Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-users] Override EAGER Fetch Relationships for a query

Hopefully just need a nudge up the learning curve...

I'm investigating the porting of an EJB tier implemented in OpenJPA/EJB to
Eclipselink, primarily to leverage the CriteriaAPI.

Our Entity contract is that the ONE side of any relationships are eagerly
loaded, so it's always safe for a client to traverse up the hierarchy for
any returned @Entity ala orderline.getOrder().getCustomer().  The MANY side
is provided for only in the EJB API, via methods like getOrders(customer).

OpenJPA has a query property, MaxFetchDepth, that limits how far up our
EAGER FETCH hierarchy to populate.  We've implemented the following static
package method that is called pretty extensively within our ejb tier,
typically with a called with a depth of 0 to circumvent any eager fetching,
but 1 is fairly common, and 2 exists:

	List listForDepth(final Query qry, final int depth){
		final OpenJPAQuery oq = OpenJPAPersistence.cast(qry);
		return qry.getResultList();

Implementation specific logic is nicely isolated and loosely coupled. 
Blissfully ignorant of the data model or that the result of the query
contains references to member A, B, and Q.getR().getS().getT() that may or
may not be populated.

Is there anything similar under Eclipselink?  I'm hoping someone can point
me somewhere, but all I've come up with is...

The FetchGroupManager/FetchGroup APIs initially looked promising, but it
seems that my entity's would have to implement the FetchGroupTracker
interface, of which the '_persistence_isAttributeFetched(attribute)'
signature indicates a singleton definition approach, ie: either fetch this
member or don't.  I guess that's a default, and that multiple FG definitions
could override.  The show stopper is the FGTracker interface's exposure of
'_persistence_getSession() ', which seems would allow a client access to
things like 'executeQuery("Delete * from Billing where b.customer in
meAndMyFriends;")'.   Can't implement that interface on any public @Entity.

Best I've come up with is that I can cast the query using
JpaHelper.getReadAllQuery(...), and call addPartialAttribute(...) for every
member that I want, including traversing up the requested depth's members as
well.  Have to tie any implementation tightly to the data model, or
introduce reflection, or require any callers to pass me a self-configured
ReadAllQuery.  No longer nicely encapsulated or loosely coupled.

I must be missing something.  Any pointers would be greatly appreciated.


View this message in context:
Sent from the EclipseLink - Users mailing list archive at

Back to the top