openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Vorburger" <mvorbur...@odyssey-group.com>
Subject RE: Fetch Group questions
Date Thu, 07 Aug 2008 02:08:48 GMT
1. Thanks, that works great.

2. OK; understand perfectly what your saying; thanks for detailing. (Now
our data architect WILL probably cry that "there are unncessary columns
fetched!".  In the "upper layer" that is creating the FetchPlan,
dynamically, we would actually have the information to know that we will
NOT access A.c or A.c, so if a future OpenJPA version would offer a way
to override this,per attribute not globally, we could leverage that; but
it's certainly not critical.  Do you want a JIRA for this?)

3. Ignore; I think correctly configured Eager Fetching is what I'm
looking for; need to play more with this. I'll ask more specific
questions if needed.

4. Hm... I see.  So to be safe, until this "bug" (?) gets addressed (can
it? will it? Would a JIRA help?), or actually rather for the combination
of Cache/FetchGroup to work at all, would it be a good idea to may be
split all Entities into two types: A. fully cached ones (all instances
with "ALL" FetchGroup pinned in memory) - that should work well for
"lookup table" kind of Entites. No FetchGroups used.  B. No caching of
all other Entites (most Business Entites, all with lot's of columns),
and use of FetchGroups - good idea?  Q: Is there a runtime API to the
@DataCache(enabled=false), some configuration API to set which classes
(globally, given a Class, not an instance) should be cached and which
not?

4 1/2 [NEW] Q: On a Query where an association to a "fully cached"
Entity IS in the FetchGroup, can OpenJPA know this and NOT do the JOIN?
(Otherwise I'll think about building this into a layer on top, although
it would be nicer if OpenJPA itself could handle this...)

5. [NEW] Q: Is there any significant runtime performance difference
between putting the @FetchGroup/s annotation on an @Entity and merely
"activating" it through FetchPlan.addFetchGroup(String groupName), as
opposed to "building" it and using lot's of invididual
FetchPlan.addField() ?  Probably not, but I thought I'd ask.

Thanks!



-----Original Message-----
From: Pinaki Poddar [mailto:ppoddar@apache.org] 
Sent: jeudi, 31. juillet 2008 02:13
To: users@openjpa.apache.org
Subject: Re: Fetch Group questions


Hi,
> 1. Is the "default" fetch group ALWAYS active? 
Almost ALWAYS. Unless you really, seriously do not want it, force
removal by
   FetchPlan.removeFetchGroup(FetchGroup.NAME_DEFAULT);

after clearFetchGroup(), it will still load the fields of default fetch
group after resetFetchGroup(), it will load the default + any other
configured fetch groups.

> 2. Is there any way to configure OpenJPA to NOT eagerly fetch direct 
> relations

OpenJPA is not really 'fetching' the direct relation unless it is
included in the fetch group. If a row for A is read from database and
row(A) contains foreign keys to row(B) and row(C) (as the case may be
for direct to-one mappings), then those FK values are read and stored in
a way that is invisible to user application. The reference A.b or A.c is
not populated.
The intermediate storage of foreign keys optimizes any subsequent
traversal of A.b and A.c without a join. 

Once A has lots of to-one relations, it is a valid concern that A will
store a lot of FK values in intermediate storage (perhaps without ever
using them), but just wanted to underline that there is no significant
performance penalty in such cases as the values are read from an
existing row. 


> 3. When I do FetchPlan.addField() for a @ManyToMany or a 
> @PersistentCollection(elementEmbedded = true) field, there is no eager

> fetching (like when the same field has FetchType.EAGER)... Should this
work? Can somebody point to any examples or test cases for this? Do we
need to fiddle with the EagerFetchMode join/parallel??

Not sure I understand the question -- can you please elaborate?
 
> a) in other words, query caching uses the Fetch Group as cache key)
No. 

> b) only the "missing" columns are fetched and "merged" ?
No. 
If fetch plan is the only thing that is different between query Q1 and
Q2 and QueryCache is enabled,  executing Q1 followed by Q2 will produce
an incorrect behavior. OpenJPA will consider Q2 as the same as cached
version
Q1 and will never apply fetch plan of Q2. 


--
View this message in context:
http://n2.nabble.com/Fetch-Group-questions-tp534861p661340.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.


____________________________________________________________

 This email and any files transmitted with it are CONFIDENTIAL and intended
  solely for the use of the individual or entity to which they are addressed.
 Any unauthorized copying, disclosure, or distribution of the material within
  this email is strictly forbidden.
 Any views or opinions presented within this e-mail are solely those of the
  author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
 An electronic message is not binding on its sender. Any message referring to
  a binding engagement must be confirmed in writing and duly signed.
 If you have received this email in error, please notify the sender immediately
  and delete the original.

Mime
View raw message