openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henno Vermeulen <>
Subject RE: best way for very shallow fetching of entities?
Date Tue, 16 Nov 2010 14:53:53 GMT
Thank you, your CustomerFragment approach is interesting! It should in fact also work for my
bonus question which I don't think will work with fetchplans.
We have a client/server architecture where we always detach our entities using a fetchplan
so we have such staleness issues anyway.

For your second option, I assume that I can also use a JPA query to fetch the names? Because
I'm also writing the client I could also decide to fetch the names in a separate query so
that there is no black population magic going on.
I think the drawback to this method is that I need to repeat such a query for each different
query that involves a Contact.
I could instead perhaps do it in a PostLoad but I don't want n + 1 select trouble.

-----Oorspronkelijk bericht-----
Van: No1UNo [] 
Verzonden: dinsdag 16 november 2010 15:29
Onderwerp: Re: best way for very shallow fetching of entities?

Let me assume that the shallow fetch is essentially an index over a set of large and/or complex
entities.  As such, the index entities are read-only.  This is not to say that the content
cannot be changed but that doing so would require fetching the full entity and then changing
the data there.

One option is to define two entities sharing the same table.  You would have the full version,
Customer, and a read-only shallow version CustomerFragment.  Contact would contain both. 
The first would be LAZY and the second EAGER. Both would be cached by OpenJPA but there is
a risk that the cache content would be stale.  In other words, changing the name field of
Customer might not update the associated CustomerFragment in cache.

A second option is to have CustomerFragment as a transient field which you manually populate
via a native query.

On Nov 16, 2010, at 6:39 AM, Henno Vermeulen [via OpenJPA] wrote:

> What is the best way to fetch complex entities extremely shallowly: only a name field,
the id and version? 
> The normal way we work is by fetching primitive fields eagerly (which is the default),
marking our relations as LAZY and making FetchGroups for them to be used in FetchPlans. 
> One solution I can think of is marking each and every primitive field as LAZY and make
a fetchgroup that contains them all. But this gives some code clutter and is not very maintainable:
we should not forget to map each new field as lazy and include it in the FetchGroup. Also
all previous FetchPlans should now include this new FetchGroup. 
> Should we call entityManager.getFetchPlan().clearFetchGroups() to clear everything and
then simply add the name field? I think this has the drawback that we should not forget to
do this in each query that involves the same entity. Would it be possible to have a FetchGroup
that specifies fields that should NOT to be fetched instead of fields to be fetched? 
> Our use case: we have a Customer and Contact (a person) that have a many-to-many relation
between them. We wish to be able to fetch a Contact with all its Customers but only need the
Customer names and nothing more so that performance is better. 
> Bonus question: 
> Is it possible to set a fetch plan such that we fetch a Customer (deeply: with some relations
to other entities), fetch its Contacts and for each of these Contacts fetch the Customers
with ONLY their names??? 
> A use case for this is a GUI for editing one Customer together with its Contacts and
be able to see for each Contact that it is used in other Customers as well. 
> Regards, 
> Henno Vermeulen 
> View message @

> To start a new topic under OpenJPA Users, email

> To unsubscribe from OpenJPA Users, click here.

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

View raw message