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
> [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-tp5743478p5746423.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
