Great, thanks for answering that question. It's nice to know it's a possible solution; as we can see from the Bryce Cottam, James H, Diana Cruise, et. al. thread, dealing with these unowned child objects that are in various places, it's a puzzle.
My latest thinking is that using clone() for this probably isn't a good idea; later on I may need a real clone, and for this my clone would probably not do a deep copy. Jason (Google) wrote: > 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > > > > > 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 [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 -~----------~----~----~----~------~----~------~--~---
