You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com> on 2009/07/29 16:13:57 UTC
Dynamic fetch plan question
Hi,
I'm reading doc on fetch plan and fetch group (I discover that feature).
What I want to do is to dynamically specify the attribute (atomic or
not) for a query in order to get back a List<A> with partial values
rather than a List<Object[]>.
I feel it is possible reading the doc, but there are still some "black
hole" in my mind.
Questions from the doc example :
OpenJPAEntityManager kem = OpenJPAPersistence.cast(em);
// Question 1 : does it mean that EntityManager was in fact an
instance of OpenJPAEntityManager ?
kem.getFetchPlan().addField(Magazine.class, "publisher");
// Question 2 : OK, here it works because publisher is a "relational
"attribute that was set to lazy with annotation.
// So that call make it eager dynamically but what about "non
relational" @Basic attribute ? They can't be lazy or eager.
// So, how do I dynamically add/remove @Basic attributes from being
retreive using fetch plan ? Is it possible ?
//
// Do you think I could (should ?) remove all fields from fetch plan
and then add one by one so I won't have to deal with eager or lazy
annotation ?
Magazine mag = em.find(Magazine.class, magId);
// Question 3 : will all that work with a query that get back several
Magazine ?
// something like that for example :
final String ql = "SELECT m FROM Magazine m";
final Query query = em.createQuery(ql);
final List<Magazine> requestResult = query.getResultList();
Re: Dynamic fetch plan question
Posted by Pinaki Poddar <pp...@apache.org>.
Hi,
The concept of Fetch Plan in particular and the perspective of data as
graph (as opposed to rows in a table) are prevalent in non-RDBMS world for
many years. JDO (JSR-12) -a precursor to JPA in many ways - had specified
FetchPlan in its API. The "only RDBMS" view of the world does not see fetch
as orthogonal to selection. But, at times, being a minority has its own
pleasures ...
OpenJPA has provided the core facilities in terms of fetch plan, detach
(before JPA 2.0 made it a standard), reattach/merge, Detach State
Management-- that can be utilized to build high-performance multi-tier web
application *without* any need to break the unified domain abstractions
through Data Transfer Objects, Data Access Objects etc. across the
application tiers.
Jean-Baptiste BRIAUD -- Novlog wrote:
>
> I already read that blog post and that's after reading it that I
> decided to try OpenJPA.
> I spent a lot of time as a consultant, in previous life, to educate
> people to that concept in the early 2002-2003.
> It was with OJB (as far as I remember) and I didn't know how to name
> that "thing".
>
> That blog post was like a flash of light in my mind : not only I'm not
> alone wanting that feature but it is now well understood and named
> "fetch plan" and more important, it has been implemented in an Apache
> framework so I won't have to code all the machinery myself !
>
> I won't felt lonly anymore, thanks OpenJPA :-)
>
> On Aug 5, 2009, at 15:40 , Pinaki Poddar wrote:
>
>>
>>> That is really so po-wer-full : it works also on request and it solve
>> entierly the problem !
>>
>> fyi...
>>
>>
>> http://webspherepersistence.blogspot.com/2009/02/dynamic-fetch-planning.html
>>
>>
>>
>> -----
>> Pinaki
>> --
>> View this message in context:
>> http://n2.nabble.com/Dynamic-fetch-plan-question-tp3350020p3391768.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>
>
>
-----
Pinaki
--
View this message in context: http://n2.nabble.com/Dynamic-fetch-plan-question-tp3350020p3394908.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Dynamic fetch plan question
Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.
I already read that blog post and that's after reading it that I
decided to try OpenJPA.
I spent a lot of time as a consultant, in previous life, to educate
people to that concept in the early 2002-2003.
It was with OJB (as far as I remember) and I didn't know how to name
that "thing".
That blog post was like a flash of light in my mind : not only I'm not
alone wanting that feature but it is now well understood and named
"fetch plan" and more important, it has been implemented in an Apache
framework so I won't have to code all the machinery myself !
I won't felt lonly anymore, thanks OpenJPA :-)
On Aug 5, 2009, at 15:40 , Pinaki Poddar wrote:
>
>> That is really so po-wer-full : it works also on request and it solve
> entierly the problem !
>
> fyi...
>
>
> http://webspherepersistence.blogspot.com/2009/02/dynamic-fetch-planning.html
>
>
>
> -----
> Pinaki
> --
> View this message in context: http://n2.nabble.com/Dynamic-fetch-plan-question-tp3350020p3391768.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
Re: Dynamic fetch plan question
Posted by Pinaki Poddar <pp...@apache.org>.
> That is really so po-wer-full : it works also on request and it solve
entierly the problem !
fyi...
http://webspherepersistence.blogspot.com/2009/02/dynamic-fetch-planning.html
-----
Pinaki
--
View this message in context: http://n2.nabble.com/Dynamic-fetch-plan-question-tp3350020p3391768.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Dynamic fetch plan question
Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.
On Jul 29, 2009, at 16:13 , Jean-Baptiste BRIAUD -- Novlog wrote:
> Hi,
>
> I'm reading doc on fetch plan and fetch group (I discover that
> feature).
> What I want to do is to dynamically specify the attribute (atomic or
> not) for a query in order to get back a List<A> with partial values
> rather than a List<Object[]>.
> I feel it is possible reading the doc, but there are still some
> "black hole" in my mind.
>
> Questions from the doc example :
>
> OpenJPAEntityManager kem = OpenJPAPersistence.cast(em);
> // Question 1 : does it mean that EntityManager was in fact an
> instance of OpenJPAEntityManager ?
>
> kem.getFetchPlan().addField(Magazine.class, "publisher");
> // Question 2 : OK, here it works because publisher is a "relational
> "attribute that was set to lazy with annotation.
> // So that call make it eager dynamically but what about "non
> relational" @Basic attribute ? They can't be lazy or eager.
> // So, how do I dynamically add/remove @Basic attributes from being
> retreive using fetch plan ? Is it possible ?
> //
> // Do you think I could (should ?) remove all fields from fetch plan
> and then add one by one so I won't have to deal with eager or lazy
> annotation ?
>
Still not sure about that, look like not needed as I trace fetch plan
contain nothing defined eager with annotation.
> Magazine mag = em.find(Magazine.class, magId);
> // Question 3 : will all that work with a query that get back
> several Magazine ?
> // something like that for example :
> final String ql = "SELECT m FROM Magazine m";
> final Query query = em.createQuery(ql);
> final List<Magazine> requestResult = query.getResultList();
That is really so po-wer-full : it works also on request and it solve
entierly the problem !