From dev-return-5516-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Mon Aug 13 21:17:46 2007 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 46147 invoked from network); 13 Aug 2007 21:17:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Aug 2007 21:17:46 -0000 Received: (qmail 23004 invoked by uid 500); 13 Aug 2007 21:17:43 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 22984 invoked by uid 500); 13 Aug 2007 21:17:43 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 22975 invoked by uid 99); 13 Aug 2007 21:17:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Aug 2007 14:17:43 -0700 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=MSGID_FROM_MTA_HEADER,SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [17.250.248.181] (HELO smtpout.mac.com) (17.250.248.181) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Aug 2007 21:17:40 +0000 Received: from webmail019 (webmail019-s [10.13.128.19]) by smtpout.mac.com (Xserve/smtpout11/MantshX 4.0) with ESMTP id l7DLHHw0020423 for ; Mon, 13 Aug 2007 14:17:17 -0700 (PDT) Date: Mon, 13 Aug 2007 14:17:17 -0700 From: Joe Grassel To: dev@openjpa.apache.org Message-ID: in-reply-to: <7262f25e0708131336n1f9ba4d4q87d735c87b084839@mail.gmail.com> references: <7262f25e0708131236x35882c43rcc6a8f6f416084cc@mail.gmail.com> <7262f25e0708131324t5b34080dnbf5c936a1f04daa9@mail.gmail.com> <7262f25e0708131336n1f9ba4d4q87d735c87b084839@mail.gmail.com> Subject: Re: Fetch Groups MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 129.42.161.36 Received: from [129.42.161.36] from webmail.mac.com with HTTP; Mon, 13 Aug 2007 14:17:17 -0700 X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Virus-Checked: Checked by ClamAV on apache.org Ok, I commented out all the @FetchGroup annotations, and commented out the lines that add the fetchgroups to the fetchplan. I still had the curious behavior that my address 1:1 relationship, now annotated explicitly as eager, was still not getting loaded, in fact it started coming up null instead of a proxy object even. however, after I commented out these preceding lines (they appear before adding my fetchgroups to the plan, I probably should have included them in my code snipper earlier): // oem.getFetchPlan().clearFetchGroups(); // oem.getFetchPlan().clearFields(); Then the address relationship started displaying eager behavior. Did either or both of the clear* operations remove the default fetch group from the plan? If so, is that the intended function? I thought the clear*() operations were to remove any custom fetchgroups that were added to the plan, and left default alone. On Monday, August 13, 2007, at 03:36PM, "Patrick Linskey" wrote: >What if you remove the fetch group annotations, and just set fetch >type to eager on the relation? If that, or that + @Basic, works, then >it must be a problem with our fetch group traversal application. > >-Patrick > >On 8/13/07, Joe Grassel wrote: >> No change: >> >> SELECT t0.EMP_TYPE, t1.id, t0.dept_id, t0.description, t0.manager_id FROM Employee t0 LEFT OUTER JOIN Address t1 ON t0.address_id = t1.id WHERE t0.id = ? [params=(int) 1] >> >> On Monday, August 13, 2007, at 03:25PM, "Patrick Linskey" wrote: >> >Hmm. What happens if you put @Basic annotations on the fields in Address? >> > >> >-Patrick >> > >> >On 8/13/07, Joe Grassel wrote: >> >> Looks like the only query that goes out is: >> >> >> >> >> >> [main] openjpa.jdbc.SQL - executing prepstmnt 1983018546 SELECT t0.EMP_TYPE, t1.id, t0.dept_id, t0.description, t0.manager_id FROM Employee t0 LEFT OUTER JOIN Address t1 ON t0.address_id = t1.id WHERE t0.id = ? [params=(int) 1] >> >> >> >> >> >> On Monday, August 13, 2007, at 02:37PM, "Patrick Linskey" wrote: >> >> >> Is this a bug in OpenJPA, or is a proxy object supposed to be in the Address entity's place? >> >> > >> >> >I would expect the address data to be available. >> >> > >> >> >What SQL is produced by the find call? >> >> > >> >> >-Patrick >> >> > >> >> >On 8/13/07, Joe Grassel wrote: >> >> >> Hello, I'm writing a program that is trying to capitalize on FetchGroups, but I'm hitting some behavior that I was not expecting, based on what I read from the manual. >> >> >> >> >> >> I have two entities, Employee and Address, as follows: >> >> >> >> >> >> @Entity >> >> >> @FetchGroups({ >> >> >> @FetchGroup(name="DescFetchGroup", attributes= {@FetchAttribute(name="description")} ), >> >> >> @FetchGroup(name="AddressFetchGroup", attributes= {@FetchAttribute(name="address")} ) >> >> >> //... >> >> >> }) >> >> >> public class Employee { >> >> >> @Id >> >> >> private int id; >> >> >> >> >> >> //... >> >> >> >> >> >> @Basic(fetch=FetchType.LAZY) >> >> >> private String description; >> >> >> >> >> >> @OneToOne(fetch=FetchType.LAZY) >> >> >> private Address address; >> >> >> >> >> >> //... >> >> >> >> >> >> } >> >> >> >> >> >> and >> >> >> >> >> >> @Entity >> >> >> public class Address { >> >> >> @Id >> >> >> private int id; >> >> >> >> >> >> private String street; >> >> >> private String city; >> >> >> private String state; >> >> >> private int zip; >> >> >> >> >> >> //... >> >> >> >> >> >> public String toString() >> >> >> { >> >> >> StringBuffer sb = new StringBuffer(); >> >> >> sb.append("Address(id=").append(this.id).append(")"); >> >> >> sb.append(": street=").append(getStreet()); >> >> >> sb.append(": city=").append(getCity()); >> >> >> sb.append(": state=").append(getState()); >> >> >> sb.append(": zip=").append(getZip()); >> >> >> >> >> >> return new String(sb); >> >> >> } >> >> >> } >> >> >> >> >> >> This is what I'm trying to do: >> >> >> >> >> >> // ... >> >> >> OpenJPAEntityManager oem = (OpenJPAEntityManager) em; >> >> >> oem.getFetchPlan().addFetchGroups("DescFetchGroup"); >> >> >> oem.getFetchPlan().addFetchGroups("AddressFetchGroup"); >> >> >> >> >> >> oem.clear(); >> >> >> Employee emp = oem.find(Employee.class, 1); >> >> >> oem.clear(); >> >> >> >> >> >> if (emp.getDescription() != null) >> >> >> System.out.println("Employee description=" + emp.getDescription()); >> >> >> else >> >> >> System.out.println("Description is null"); >> >> >> >> >> >> if (emp.getAddress() != null) >> >> >> System.out.println("Employee address=" + emp.getAddress()); >> >> >> else >> >> >> System.out.println("Address is null"); >> >> >> >> >> >> // ... >> >> >> >> >> >> I get the following results: >> >> >> >> >> >> Employee description=Description 1 >> >> >> Employee address=Address(id=1): street=null: city=null: state=null: zip=0 >> >> >> >> >> >> It looks like an empty proxy object containing just the Address entity's primary key is returned. I was under the impression that with the AddressFetchGroup added to the fetch plan, that the whole (Address) entity's persistent state would be eagerly loaded. >> >> >> >> >> >> Is this a bug in OpenJPA, or is a proxy object supposed to be in the Address entity's place? >> >> >> >> >> > >> >> > >> >> >-- >> >> >Patrick Linskey >> >> >202 669 5907 >> >> > >> >> > >> >> >> > >> > >> >-- >> >Patrick Linskey >> >202 669 5907 >> > >> > >> > > >-- >Patrick Linskey >202 669 5907 > >