The overhead of having to fetch the "inner object" is negligible since you're using a direct fetch by key. You can set a @NotPersistent property of the intended type and modify your DAO methods to fetch both objects (User and FavoriteFood) and set the @NotPersistent property of the User to this fetched object. It's a few extra lines but you get the convenience of being able to access the inner object directly without polluting your datastore with cloned objects.
- Jason On Sat, Oct 31, 2009 at 4:21 PM, Rusty Wright <rwright.li...@gmail.com>wrote: > > Yes, that's the point. My thinking is that (correct me if I'm wrong) if I > store the object's key, when I fetch the outer containing object that has > its key, I'll need to use the key to fetch the object. By cloning it, I > don't need to do that, I just fetch the outer object and the inner object > will get fetched along with it (assuming it's in the default fetch group). > Whenever I want the outer object I'll also want its inner objects. > > If I store the key in the outer object, when I fetch the outer object it > seems to me that I'll then need to fetch the contained object. And I'll > have two fields on the outer object; using my FavoriteFood example, I'll > need a field favoriteFoodKey, type Key, which is persisted, and a > favoriteFood, type FavoriteFood, which is transient, and not persisted. > Then my jsp would use the getter for the favoriteFood field. > > This is why I'm asking; it seems a bit complicated. Perhaps there's a > simpler way that I could use. > > In my case, there isn't a lot of data so the duplication of objects isn't a > big issue. > > > John Patterson wrote: > > Why are you cloning instead of setting the original object? JDO will > > store the clone as a separate entity in the datastore. > > > > 2009/11/1 Rusty Wright <rwright.li...@gmail.com > > <mailto:rwright.li...@gmail.com>> > > > > > > I'm trying to figure out the best way to manage root objects that > > are used with different objects. For a semi concrete example, > > suppose you have a web page with a drop down list of Favorite Foods, > > and a User object may have a reference to a FavoriteFood, and other > > objects will have references to FavoriteFood objects as well. > > > > It seems to me that if individual FavoriteFood objects don't change, > > but the list (table) of FavoriteFood objects can grow, you could > > make them Cloneable and use the clone, making it a child, for > example: > > > > FavoriteFood fav = favoriteFoodDao.findByStringId(stringId); > > user.addFavoriteFood(fav.clone()); > > > > Google's examples usually (always?) store the subordinate object's > > Key rather than a clone of the object. > > > > I can see problems with using clones; even though I'm sure they > > won't, they may change. Similarly, items may need to be deleted > > from the master FavoriteFood list/table. There may be other > > problems that I haven't thought of. > > > > Anyhow, I'm wondering if others have gone done this road or > > investigated it and can offer advise. > > > > Thanks > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~----------~----~----~----~------~----~------~--~---
