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. > > > > > > > > > > > > > > >
