but then it would be again an owned relationship, which I actually wanted to avoid...
On 13 Nov., 06:33, Rusty Wright <rwright.li...@gmail.com> wrote: > One of the things I've been wondering about is if it helps to invert the > ownership. > > Thinking out loud again. Feedback welcome; feel free to point out flaws in > my logic, or whatever. > > For example, if you have a class Person with favorite foods, with an rdbms > you'd have: > > @PersistenceCapable(identityType = IdentityType.APPLICATION, detachable = > "true") > class Person { > @PrimaryKey > @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) > private Long id; > > @Persistent(defaultFetchGroup = "true") > private Set<FavoriteFood> favoriteFoods = new HashSet<FavoriteFood>(); > > etc. > > } > > @PersistenceCapable(identityType = IdentityType.APPLICATION, detachable = > "true") > class FavoriteFood { > @PrimaryKey > @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) > private Long id; > > etc. > > } > > But with GAE's Big Table this doesn't work if you want to share the > FavoriteFood entities because when you add them to Person's favoriteFoods > collection it wants to make Person their parent. > > So with GAE what you could do is: > > @PersistenceCapable(identityType = IdentityType.APPLICATION, detachable = > "true") > class Person { > @PrimaryKey > @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) > @Extension(vendorName = "datanucleus", key = "gae.encoded-pk", value = > "true") > private String id; > > @Persistent(defaultFetchGroup = "true") > private Set<String> favoriteFoods = new HashSet<String>(); > > etc. > > } > > @PersistenceCapable(identityType = IdentityType.APPLICATION, detachable = > "true") > class FavoriteFood { > @PrimaryKey > @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) > @Extension(vendorName = "datanucleus", key = "gae.encoded-pk", value = > "true") > private String id; > > etc. > > } > > And if a Person's favorite food is haggis, you'd do a query to get the haggis > entity, then store its id in the Person's favoriteFoods Set. (And you could > use Key instead of String.) > > But what if you invert the relationship; make FavoriteFoods the aggregator; > so instead of people having a list of favorite foods, the favorite foods have > a list of people for whom they're their favorites: > > @PersistenceCapable(identityType = IdentityType.APPLICATION, detachable = > "true") > class Person { > @PrimaryKey > @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) > @Extension(vendorName = "datanucleus", key = "gae.encoded-pk", value = > "true") > private String id; > > etc. > > } > > @PersistenceCapable(identityType = IdentityType.APPLICATION, detachable = > "true") > class FavoriteFood { > @PrimaryKey > @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) > @Extension(vendorName = "datanucleus", key = "gae.encoded-pk", value = > "true") > private String id; > > @Persistent(defaultFetchGroup = "true") > private Set<String> persons = new HashSet<String>(); > > etc. > > } > > I'm wondering if in some cases modeling things this way may make things > easier to manage. For example, you may be able to store the object (instead > of its id) in the Set and let it become the child; perhaps the parenting > issues going in that direction are less irksome. > > > > James H wrote: > > This seems to be at the core of much confusion...hopefully one of the > > persistence experts will weigh in and enlighten us. I keep watch on > > this thread and weigh in a bit later, in a rush at the moment! > > > On Nov 11, 7:39 am, "a.maza" <andr.m...@gmail.com> wrote: > >> I am thinking if it makes sense from a design perspektive to model > >> unowned bi-directional one-to-many relationships.I did some search on > >> the web but didn't find many thoughts about such type of relationship. > > >> The two entity types I have should not be in an owned relationship for > >> some reasons. Thus, I was thinking about using the relation index > >> pattern as presented at Google I/O (http://code.google.com/intl/de-AT/ > >> events/io/2009/sessions/BuildingScalableComplexApps.html) > > >> However, I am not fully happy with that as outlined in another thread > >> (http://groups.google.com/group/google-appengine-java/browse_thread/ > >> thread/2bba41ce4699d65e/918fee627cc41e02?#918fee627cc41e02) mainly due > >> to performance issues when iterating over the keys in memory. > > >> Thus I was thinking about modeling the two entities in an unowned bi- > >> directional style implying that I have to update the two entities in > >> separate transactions in order to keep the relationship between the > >> two entities. I would like to hear your thoughts about this. My main > >> concern is consistency when something goes wrong in one of the two > >> transactions. > > >> thanks, > >> andr > > --~--~---------~--~----~------------~-------~--~----~ > > 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 > > athttp://groups.google.com/group/google-appengine-java?hl=en > > -~----------~----~----~----~------~----~------~--~---- Zitierten Text > > ausblenden - > > - Zitierten Text anzeigen - -- 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-j...@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=.