openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From No1UNo <je...@jerrycarter.org>
Subject Re: best way for very shallow fetching of entities?
Date Wed, 17 Nov 2010 03:35:31 GMT


On Nov 16, 2010, at 9:54 AM, Henno Vermeulen [via OpenJPA] wrote:

> 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. 

Doing a separate query for each row is certainly one option, but you might be better with
a combination such as:

SELECT contact.id AS contact,customer.id,customer.version,customer.name
	FROM contact,customer WHERE ... ORDER BY contact.id

Then walk through the collection of contacts and populate as needed.

> ___________________________________________________________________________________ 
> 
> 
> -----Oorspronkelijk bericht----- 
> Van: No1UNo [mailto:[hidden email]] 
> Verzonden: dinsdag 16 november 2010 15:29 
> Aan: [hidden email] 
> 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 @ http://openjpa.208410.n2.nabble.com/best-way-for-very-shallow-fetching-of-entities-tp5743478p5743478.html
 
> > To start a new topic under OpenJPA Users, email [hidden email] 
> > To unsubscribe from OpenJPA Users, click here. 
> >
> 
> 
> -- 
> View this message in context: http://openjpa.208410.n2.nabble.com/best-way-for-very-shallow-fetching-of-entities-tp5743478p5743984.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com. 
> 
> 
> View message @ http://openjpa.208410.n2.nabble.com/best-way-for-very-shallow-fetching-of-entities-tp5743478p5744080.html

> To start a new topic under OpenJPA Users, email ml-node+208411-1703014788-244680@n2.nabble.com

> To unsubscribe from OpenJPA Users, click here.
> 


-- 
View this message in context: http://openjpa.208410.n2.nabble.com/best-way-for-very-shallow-fetching-of-entities-tp5743478p5746423.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message