Thanks Kevin I think this is a really good suggestion -- although it may incur some problems to the various users of the existing code where the conditions are not right for lazy loading. But definitely worth investigation.
Do you also mean to say that overriding the defined fetch-type or affecting the default fetch plan is something that could be brought forward to the openjpa community ? Stephen -------------------------------------------------------------------------- Stephen Hallinan, Software Engineer Phone 604.408.8078 ext. 258 Mobile: 778.668.8654 Email: [email protected] Elastic Path Software, Inc. Web: www.elasticpath.com Blog: www.getelastic.com Community: grep.elasticpath.com Careers: www.elasticpath.com/jobs Confidentiality Notice: This message is intended only for the use of the designated addressee(s), and may contain information that is privileged, confidential and exempt from disclosure. Any unauthorized viewing, disclosure, copying, distribution or use of information contained in this e-mail is prohibited and may be unlawful. If you received this e-mail in error, please reply to the sender immediately to inform us you are not the intended recipient and delete the email from your computer system. Thank you. -----Original Message----- From: Kevin Sutter [mailto:[email protected]] Sent: November 10, 2010 7:03 AM To: [email protected] Subject: Re: subclass lazy fetching Hi Stephen, Yes, you might be right that we can't affect the default fetch plan. You might have to define your own custom fetch plan for this scenario. I also noticed this statement in the documentation: "In all methods, the named field must be defined in the class specified in the invocation, not a superclass." So, in your case, you would need to specify the class name as your superclass in your addField/removeField invocation. So, now I'm wondering whether this approach will work for you. Maybe you would have to reverse your configuration and start with a Lazy defined field and then make it Eager when necessary. This sounds like a good scenario that should be able to work, but maybe with some effort. If you are game to help define a junit test and contribute a doc or code patch, I'm sure they would be appreciated by the community. I've also pinged a few other members to see if they have any insights... Good luck, Kevin On Tue, Nov 9, 2010 at 12:16 PM, Stephen Hallinan < [email protected]> wrote: > > Hi Kevin > > Thanks for the reply again. > > I actually tested this out, by casting to fetchplanimpl and attempting a > removeField, but it looks like that does not affect the default fetch plan. > > Also, I have attempted to create a subclass and override the field > annotations in xml to specify the fetch type LAZY, but when you query for > this subclass it does not make a difference to what is returned. > > Stephen > > > > -------------------------------------------------------------------------- > Stephen Hallinan, Software Engineer > Phone 604.408.8078 ext. 258 > Mobile: 778.668.8654 > Email: [email protected] > > Elastic Path Software, Inc. > Web: www.elasticpath.com > Blog: www.getelastic.com > Community: grep.elasticpath.com > Careers: www.elasticpath.com/jobs > > Confidentiality Notice: This message is intended only for the use of the > designated addressee(s), and may contain information that is privileged, > confidential and exempt from disclosure. Any unauthorized viewing, > disclosure, copying, distribution or use of information contained in this > e-mail is prohibited and may be unlawful. If you received this e-mail in > error, please reply to the sender immediately to inform us you are not the > intended recipient and delete the email from your computer system. Thank > you. > > -----Original Message----- > > From: Kevin Sutter [mailto:[email protected]] > Sent: November 9, 2010 9:56 AM > To: [email protected] > Subject: Re: subclass lazy fetching > > Hi Stephen, > Check out the complete FetchPlan interface [1]. The addField would add > another field to be fetched. The removeField does the opposite and removes > the field from fetching. > > You could search through our JUnits to see if there's an example (I don't > have access at the moment). > > Kevin > > [1] > > http://openjpa.apache.org/builds/2.0.1/apache-openjpa-2.0.1/docs/javadoc/org/apache/openjpa/persistence/FetchPlan.html > > On Tue, Nov 9, 2010 at 11:20 AM, Stephen Hallinan < > [email protected]> wrote: > > > Hi Kevin > > > > Do you mean example 5.22 ? > > > > OpenJPAEntityManager kem = OpenJPAPersistence.cast(em); > > kem.getFetchPlan().addField(Magazine.class, "publisher"); > > Magazine mag = em.find(Magazine.class, magId); > > > > > > I can see how this would add another field to be eagerly fetched -- but I > > don't see how I could modify an attribute in the default fetch plan to be > > lazily fetched, unless there was some way to override the annotation for > the > > particular class either in a subclass or xml ... > > > > Can you elaborate or provide a code sample for what you mean? > > > > Thanks, > > > > Stephen > > > > > > > > > -------------------------------------------------------------------------- > > Stephen Hallinan, Software Engineer > > Phone 604.408.8078 ext. 258 > > Mobile: 778.668.8654 > > Email: [email protected] > > > > Elastic Path Software, Inc. > > Web: www.elasticpath.com > > Blog: www.getelastic.com > > Community: grep.elasticpath.com > > Careers: www.elasticpath.com/jobs > > > > Confidentiality Notice: This message is intended only for the use of the > > designated addressee(s), and may contain information that is privileged, > > confidential and exempt from disclosure. Any unauthorized viewing, > > disclosure, copying, distribution or use of information contained in this > > e-mail is prohibited and may be unlawful. If you received this e-mail in > > error, please reply to the sender immediately to inform us you are not > the > > intended recipient and delete the email from your computer system. Thank > > you. > > > > -----Original Message----- > > > > From: Kevin Sutter [mailto:[email protected]] > > Sent: November 9, 2010 6:08 AM > > To: [email protected] > > Subject: Re: subclass lazy fetching > > > > Hi Stephen, > > Check out Fetch Groups and Fetch Plans [1]. Towards the end of this > > section, it shows an example of overriding the fetch plan to make an > > attribute EAGER. You should be able to do a similar operation for LAZY > > loading. This is an OpenJPA extension is not part of the JPA spec. > > > > Kevin > > > > [1] > > > > > http://openjpa.apache.org/builds/2.0.1/apache-openjpa-2.0.1/docs/manual/manual.html#ref_guide_fetch > > > > On Mon, Nov 8, 2010 at 3:11 PM, Stephen Hallinan < > > [email protected]> wrote: > > > > > Hi > > > > > > I have a scenario whereby I'd like to subclass an entity, and override > a > > > couple of the fields to have the fetch type LAZY. > > > > > > In the super class they are EAGER. > > > > > > Is this possible ? In my tests so far it seems not to be the case but > > maybe > > > there are some aspects of implementation I'm not aware of. > > > > > > Thanks, > > > > > > Stephen > > > > > > > > > > > > > > > -------------------------------------------------------------------------- > > > Stephen Hallinan, Software Engineer > > > Phone 604.408.8078 ext. 258 > > > Mobile: 778.668.8654 > > > Email: [email protected] > > > > > > Elastic Path Software, Inc. > > > Web: www.elasticpath.com > > > Blog: www.getelastic.com > > > Community: grep.elasticpath.com > > > Careers: www.elasticpath.com/jobs > > > > > > Confidentiality Notice: This message is intended only for the use of > the > > > designated addressee(s), and may contain information that is > privileged, > > > confidential and exempt from disclosure. Any unauthorized viewing, > > > disclosure, copying, distribution or use of information contained in > this > > > e-mail is prohibited and may be unlawful. If you received this e-mail > in > > > error, please reply to the sender immediately to inform us you are not > > the > > > intended recipient and delete the email from your computer system. > Thank > > > you. > > > > > > > > > > > > > > >
