Skip to main content

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

You do not need to implement anything special for FetchGroups, you just need
to enable weaving.  The session in the Entity is transient, so does not give
any remote client access to anything.  On the server any server code can
access your EntityManager or DataSource directly, so I'm not sure what
security you think you have.

FetchGroups in 2.0 only provides one level of fetching.  In the 2.1 release
(trunk) there is support for nested fetch groups.  2.1 also provides a load
policy to define what relationships to force loading, that does not require

If you normally want 0, then just make your relationships LAZY, and that is
what you will get.  In the places you need the relationship instantiated you
can either join fetch the relationship, or access the relationship after the
query to ensure it is instantiated.

The EclipseLink Session also provides a copyObject() API that will provide a
copy of an object (shallow, private, deep) that allow instantiating

JimOR wrote:
> 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);
> 		oq.getFetchPlan().setMaxFetchDepth(depth);
> 		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.
> Thanks,
> Jim

----- James Sutherland
 EclipseLink ,
Wiki: EclipseLink , TopLink 
Forums: TopLink , EclipseLink 
Book: Java Persistence 
View this message in context:
Sent from the EclipseLink - Users mailing list archive at

Back to the top