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=.


Reply via email to