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 [mailto:[email protected]] Verzonden: dinsdag 16 november 2010 15:29 Aan: [email protected] 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 > [email protected] > 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.
