I'm having the same problem. If i understand this correctly i must create an index for all fields in an entity. Otherwise it will be null when i fetch the entity?
If i set defaultFetchGroup = "true" i get this message which doesn't look promising: 8:55:05,144 WARN [DataNucleus.MetaData] - Meta-data warning for Item.values: The datastore does not support joins and therefore cannot honor requests to place child objects in the default fetch group. The field will be fetched lazily on first access. You can modify this warning by setting the datanucleus.appengine.ignorableMetaDataBehavior property in your config. A value of NONE will silence the warning. A value of ERROR will turn the warning into an exception. Should i just set this property and ignore the warning? /Erik On Sep 8, 8:56 pm, "Jason (Google)" <[email protected]> wrote: > Hi David. I believe this is expected behavior -- unindexed properties, > including Text, Blob, and reference properties as well as descendants > (PrivilegedUser in this case) are not retrieved by default. There is an > easier way to add a field to the default fetch group: > > @Persistent(defaultFetchGroup = "true") > private PrivilegedUser privilegedUser; > > Can you let me know if this works for you? If not, can you share your > PrivilegedUser class definition? > > - Jason > > On Fri, Sep 4, 2009 at 9:56 PM, David <[email protected]> wrote: > > > I’ve been working with a fairly simple data model that has an > > Organization object which contains some String members as well as a > > member variable of type PrivilegedUser. And PrivilegedUser extends a > > User, and contains only a Key and some String members. > > > @PersistenceCapable(identityType = IdentityType.APPLICATION, > > detachable="true") > > public class Organization implements Serializable { > > > �...@primarykey > > �...@persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) > > private Long id; > > > �...@persistent > > private String organizationId; > > > �...@persistent > > private String organizationName; > > > �...@persistent > > private PrivilegedUser privilegedUser; > > > …. > > > I have code running successfully under 1.2.2 which creates an > > Organization, then creates a Privileged User object, and assigns it to > > the Organization, and then makes the Organization persistent. > > Later I query by organizationId to retrieve the Organization object, > > and update the PrivilegedUser on the Organization object. > > This works fine under 1.2.2. > > > Under 1.2.5 I began getting the following error: > > You have just attempted to access field "privilegedUser" yet this > > field was not detached when you detached the object. Either dont > > access this field, or detach it when detaching the object. > > > However, after stepping through the debugger I believe the root cause > > is that the privilegedUser field is null on the Organization object > > returned from the query (the String members are still correct). This > > value is null even before I attempt to detach the Organization object > > from the PersistenceManager. > > > After seeing this behavior I modified the query code I had been using > > to include a custom fetch plan for the query. > > This did not change the behavior under 1.2.5. > > > PersistenceManager pm = PMF.get().getPersistenceManager > > (); > > > FetchGroup fetchGroup = pm.getFetchGroup(Organization.class, > > "OrganizationGroup"); > > fetchGroup.addMember("privilegedUser"); > > > // Add this group to the fetch plan (using its name) > > FetchPlan fetchPlan = pm.getFetchPlan(); > > fetchPlan.addGroup("OrganizationGroup"); > > > Query query = pm.newQuery(Organization.class); > > query.setFilter("organizationId == rhsValue"); > > query.declareParameters("String rhsValue"); > > > I don't think the following is relevant, but I’ve also noticed that > > under 1.2.5 the following exception occurs, which has been reported by > > others: > > > INFO: Failed to start reference finalizer thread. Reference cleanup > > will only occur when new references are > > created.java.lang.reflect.InvocationTargetException > > > Does this sound like a bug introduced under 1.2.5, or is this expected > > behavior that was not enforced under 1.2.2? In either case, does > > anyone have a suggestion on how to work around this issue? > > > Thanks, > > David > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~----------~----~----~----~------~----~------~--~---
