openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernando Padilla <f...@alum.mit.edu>
Subject Re: slices, collocation
Date Sun, 23 Nov 2008 19:43:54 GMT
right, thank you :)

you have re-confirmed how I thought the collocation constraint worked, 
and you also gave me a great motivation why the "replicated" feature 
came about ( as a work around for the collocation constraint ).

So now we're back to sqaure one.  Looking at my example use case, the 
collocation constraint is still too inhibiting.  I want to get rid of 
those requirements! :)

So if you wanted to remove that requirement, how would you go about it? 
  What code would you look at, etc etc.  If I want to put work into 
fixing this up, where should I begin to look, etc etc.  what are some 
possible plans.. :) :) :)






Pinaki Poddar wrote:
> 
>   One key aspect of data distribution model used in Slice is that the
> distribution policy is based at instance level and *not* at class level.
> What it implies for your given scenario is that while User U1 instance can
> be persisted in Slice A, another User instance U2 can be stored in Slice B.
> So it is not necessary that all User instances are stored in one Slice and
> all Comment instances are in a different slice and so forth. 
> 
>   But what about related instances? For the sake of concreteness let us
> consider the following instances and relations:
>   User U1 belongs to Group G1 and has commented C11, C12, C13
>   User U2 belongs to Group G1 and has commented C21
> 
> The distribution policy determines that U1 and U2 are stored in Slice A and
> B respectively.
> The collocation constraint forces that any instance reachable from U1 (i.e.
> closure of U1 in Graph theory terms) is stored in Slice A and any instance
> reachable from U2 is stored in U2. Thus, C11, C12, C13 go to Slice A while
> C21 goes to Slice B.
> 
> Where does G1 go? G1 is reachable from both U1 and U2. The only current
> option is G1 is annotated as @Replicated and identical copies of G1 are
> stored in both Slice A and B. 
> 
> Of course, collocation constraint will prohibit G1 to have a relation to U1
> and U2. So, @Replicated is mainly serves to model 'master' data i.e. data
> that are referred by many but itself refers none. However, the relationship
> is not completely lost. For example, a query such as 
>    select u from User u where u.group.name='G1'" 
> will fetch both U1 and U2 by executing parallel queries across Slice A and B
> and merging the results. 
> 
>  
> 
> Fernando Padilla wrote:
>> So, now that I have some attention, I'll post up a question I sent out a 
>> month ago.
>>
>> I want to make a connected datamodel, but I want to put objects on 
>> different databases..
>>
>> Let's say I have 3 objects:
>>
>> User (slice root)
>>   - name
>>
>> Group (slice root)
>>   - name
>>   - users
>>
>> Comment (slice grouped with group)
>>   - group
>>   - user
>>   - text
>>
>>
>> As you can see they are all inter-related.  But I let's say I want to 
>> distribute Users and Groups across databases.  But they are related, but 
>> can't be collocated.
>>
>> So can you help me understand the "collocation" limitation of slices, 
>> and a way to enhance it to remove this limitation ( if I understand it 
>> properly ).
>>
>>
>>
>> ps - If i understand the limitation, I can't have a ManyToMany 
>> relationship from Group to Users, or ManyToOne from Comment to User, 
>> instead I would have to have a set of userIds.  And I would have to load 
>> up each user object myself through code.
>>
>>
>>
>>
> 

Mime
View raw message