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:[EMAIL PROTECTED] Sent: jeudi, 31. juillet 2008 02:13 To: [email protected] 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.
