Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Henno Vermeulen <henno@huizemolenaar.nl>
To: "'users@openjpa.apache.org'" <users@openjpa.apache.org>
Date: Tue, 16 Nov 2010 15:53:53 +0100
Subject: RE: best way for very shallow fetching of entities?
Thread-Topic: best way for very shallow fetching of entities?
Thread-Index: AcuFmrzUwBqZjbUwQROzwk7jSdDNWAAATX/A
Message-ID: <1C448C478A6B4743AF19DBC3C3DCE132013EDE30B9F3@HMS.hm.local>
References: <1C448C478A6B4743AF19DBC3C3DCE132013EDE30B9C2@HMS.hm.local>
 <4B66D103-E5FF-4490-9102-69F8733C646A@jerrycarter.org>
In-Reply-To: <4B66D103-E5FF-4490-9102-69F8733C646A@jerrycarter.org>
Accept-Language: nl-NL
Content-Language: nl-NL
acceptlanguage: nl-NL
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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 fetchpl=
ans.
We have a client/server architecture where we always detach our entities us=
ing 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 t=
he 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 go=
ing on.
I think the drawback to this method is that I need to repeat such a query f=
or each different query that involves a Contact.
I could instead perhaps do it in a PostLoad but I don't want n + 1 select t=
rouble.
___________________________________________________________________________=
________


-----Oorspronkelijk bericht-----
Van: No1UNo [mailto:jerry@jerrycarter.org]=20
Verzonden: dinsdag 16 november 2010 15:29
Aan: users@openjpa.apache.org
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 wo=
uld require fetching the full entity and then changing the data there.

One option is to define two entities sharing the same table.  You would hav=
e the full version, Customer, and a read-only shallow version CustomerFragm=
ent.  Contact would contain both.  The first would be LAZY and the second E=
AGER. Both would be cached by OpenJPA but there is a risk that the cache co=
ntent 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?=20
>=20
> 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.=20
> 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 FetchPla=
ns should now include this new FetchGroup.=20
>=20
> Should we call entityManager.getFetchPlan().clearFetchGroups() to clear e=
verything 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 tha=
t should NOT to be fetched instead of fields to be fetched?=20
>=20
> 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 a=
ll its Customers but only need the Customer names and nothing more so that =
performance is better.=20
>=20
> Bonus question:=20
> 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???=20
> A use case for this is a GUI for editing one Customer together with its C=
ontacts and be able to see for each Contact that it is used in other Custom=
ers as well.=20
>=20
> Regards,=20
> Henno Vermeulen=20
>=20
>=20
> View message @ http://openjpa.208410.n2.nabble.com/best-way-for-very-shal=
low-fetching-of-entities-tp5743478p5743478.html=20
> To start a new topic under OpenJPA Users, email ml-node+208411-1703014788=
-244680@n2.nabble.com=20
> To unsubscribe from OpenJPA Users, click here.
>=20


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