Re: Fetch Groups

[Craig L Russell]

clearFetchGroups actually clears everything, including the default fetch group (according to the JDO specification). If you want to reset to the default fetch group, setFetchGroups("default") should work.

Craig

On Aug 13, 2007, at 2:32 PM, Patrick Linskey wrote:

... so maybe the clearFetchGroups() is causing the implicit fetching
of the primitives in Address to be disabled. What happens if you call
resetFetchGroups() before setting things up instead?

-Patrick

On 8/13/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:

I thought the clear*() operations were to remove any custom

fetchgroups that were added to > the plan, and left default alone.


say otherwise?


Pinaki Poddar
972.834.2865

-----Original Message-----
From: Joe Grassel [mailto:[EMAIL PROTECTED]
Sent: Monday, August 13, 2007 4:17 PM
To: dev@openjpa.apache.org
Subject: Re: Fetch Groups


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.


in my code snipper earlier):

//            oem.getFetchPlan().clearFetchGroups();
//            oem.getFetchPlan().clearFields();

Then the address relationship started displaying eager behavior.  Did

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:

clearFetchGroups() clears all the fetch groups. Does the documentation Ok, I commented out all the @FetchGroup annotations, and commented out the lines that add the fetchgroups to the fetchplan. I still had the however, after I commented out these preceding lines (they appear before adding my fetchgroups to the plan, I probably should have included them either or both of the clear* operations remove the default fetch group

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:


WHERE t0.id = ? [params=(int) 1]

On Monday, August 13, 2007, at 03:25PM, "Patrick Linskey"

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

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

Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

--
Patrick Linskey
202 669 5907

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature