Are you running the enhancer, or running without enhancement?
Is this code in a format that you could attach to a JIRA issue so we
could play around with it?
-Patrick
On 8/13/07, Joe Grassel <[EMAIL PROTECTED]> wrote:
> 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" <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]> 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" <[EMAIL
> >> PROTECTED]> wrote:
> >> >Hmm. What happens if you put @Basic annotations on the fields in Address?
> >> >
> >> >-Patrick
> >> >
> >> >On 8/13/07, Joe Grassel <[EMAIL PROTECTED]> wrote:
> >> >> Looks like the only query that goes out is:
> >> >>
> >> >>
> >> >> [main] openjpa.jdbc.SQL - <t 16515324, conn 1700554076> 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" <[EMAIL
> >> >> PROTECTED]> 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 <[EMAIL PROTECTED]> 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= [EMAIL
> >> >> >> PROTECTED](name="description")} ),
> >> >> >> @FetchGroup(name="AddressFetchGroup", attributes= [EMAIL
> >> >> >> PROTECTED](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
> >
> >
>
--
Patrick Linskey
202 669 5907
