Yes, my idea was that, in some cases, inverting the relationship could possibly 
avoid the parenting/ownership problems.  Not that it's a solution for all cases.

As far as I can figure out, the problems with objects that can't have a parent, 
are objects that move around, or that are in (referenced by) multiple objects.  
I wish there was a tutorial explaining the parenting issues, from the 
perspective of mapping java objects, using both JDO and JPA.  And then present 
ways to address the issues, with their pros and cons.  It seems to me that the 
two options we can use are to either store the primary key of the would-be 
child object in the would-be parent, or to denormalize and store the would-be 
child's data in the parent.  And with those two options, it seems to me that 
the latter is only palatable if the child's data changes infrequently or never 
changes.


a.maza wrote:
> but then it would be again an owned relationship, which I actually
> wanted to avoid...
> 
> 
> 
> On 13 Nov., 06:33, Rusty Wright <[email protected]> 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" <[email protected]> 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 [email protected]
>>> To unsubscribe from this group, send email to 
>>> [email protected]
>>> 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 [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=.
> 
> 

--

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


Reply via email to