Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Jean-Baptiste BRIAUD -- Novlog <j-b.briaud@novlog.com>
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/alternative; boundary=Apple-Mail-1-591344170
Subject: Re: Fetch plan question
Date: Mon, 7 Dec 2009 21:48:21 +0100
In-Reply-To: <12D996978341E849B21C51CC97F4771D01FAA44E@mail3.oams.com>
To: users@openjpa.apache.org
References: <0759E557-8DE9-40FD-B0AE-32604F130AF2@novlog.com>
 <12D996978341E849B21C51CC97F4771D01FAA35B@mail3.oams.com>
 <E254A638-A233-4638-BDED-6635D79FDDB9@novlog.com>
 <1B67ECC2-5E99-485A-815F-3C71E9A16A53@novlog.com>
 <12D996978341E849B21C51CC97F4771D01FAA44E@mail3.oams.com>
Message-Id: <34A39AC5-3E73-42D0-A7CD-2C39592801A2@novlog.com>

--Apple-Mail-1-591344170
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 7, 2009, at 18:57 , Michael Vorburger wrote:

> Jean-Baptiste,
Hi Michael,
>=20
> I realized that in our own in-house "framework to simply to the max =
the
> use of fetchPlan" (just like yours... and ours?) we must be doing the
> same
we may share some ideas or some directions ...

> , so I refereshed my memories by looking back at that code for you
Thanks !

> (written over a year ago) and suddenly remembered that indeed there is =
a
> little "trick", you have to:
>=20
>   fp.removeFetchGroup(FetchGroup.NAME_DEFAULT);
>=20
It was that, a big big thanks.
I'm still wondering why the API do not provide a removeAllGroups and =
removeALLFields, so even without knowing the name of any groups or =
fields, the fetch plan would be 100% empty.

I thought that it was already done by that code :
        final FetchPlan fetchPlan =3D entityManager.getFetchPlan();
        fetchPlan.clearFetchGroups();
        fetchPlan.clearFields();

Now, thanks to you, I'm doing the following :
        final FetchPlan fetchPlan =3D entityManager.getFetchPlan();
        fetchPlan.clearFetchGroups();
        fetchPlan.clearFields();
        fetchPlan.removeFetchGroup(FetchGroup.NAME_DEFAULT);

> Because (quote from doc) "any field that is eagerly loaded according =
to
> the JPA metadata rules into the built-in default fetch group. As its
> name implies, the default fetch group is active by default. You may =
also
> define your own..."
>=20
In fact, you right, I read that but I still thought I didn't have =
fetchGroup forgetting the default one.

> Does this help?  If yes, why don't you create a little Defect suggest
> that the documentation be slightly slightly improved to take this
> crystal clear?  Once you know it I guess the phrase above is clear, =
but
> if you don't, it's probably not clear enough?
Exactly that !

>  A few lines of example & explanation may have helped you?
Yes definitively, I would have notices the extra =
fetchPlan.removeFetchGroup(FetchGroup.NAME_DEFAULT);
>=20
>=20
>> Magazine mag =3D em.find(Magazine.class, magId);
>> Will it work also with a query and not only with the find(id) method =
?
>> Something like that : em.createQuery("SELECT blablabla ..."); ??
>=20
> Yes yes of course.  Make sure you also read & understand the
> =
http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/
> ref_guide_perfpack_eager.html stuff though.
>=20
OK, this was like others recents question a way to confirm what I try to =
do is correct. When something goes wrong, I always suspect my own =
understanding first.

> Ciao.
>=20
Thanks a lot, I could spent days without finding that default fetchgroup =
thing.


--Apple-Mail-1-591344170--