Slices, Collocation Constraint

[Fernando Padilla <fe...@alum.mit.edu>]

So according to the documentation, Slices has a "Collocation Constraint" 
(copied below).  Can the experts comment on this requirement?  Is there 
any way to remove or ignore that requirement?  With extra code, or 
enhancements to openjpa?  Or with accepting extra caveats?

I would like to have an object graph split across databases, and it 
would be quite annoying (but doable) to cut up the object graph, via 
storing object ids, instead of object references/relations... but that's 
just a bit disappointing..


Could we mark particular object relations to be unjoinable? So JPA would 
not generate queries that try to join across the relation, thus allowing 
slices to execute the multi-part query on the appropriate databases??






2.8. Collocation Constraint

No relationship can exist across database slices. In O-R mapping 
parlance, this condition translates to the limitation that the closure 
of an object graph must be collocated in the same database. For example, 
consider a domain model where Person relates to Adress. Person X refers 
to Address A while Person Y refers to Address B. Collocation Constraint 
means that both X and A must be stored in the same database slice. 
Similarly Y and B must be stored in a single slice.

Slice, however, helps to maintain collocation constraint automatically. 
The instances in the closure set of any newly persistent instance 
reachable via cascaded relationship is stored in the same slice. The 
user-defined distribution policy requires to supply the slice for the 
root instance only.

Re: Slices, Collocation Constraint

[Pinaki Poddar <pp...@apache.org>]

Hi,
The trunk version of Slice relaxes 'collocation constraint' by annotating
certain entity types as @Replicated and introducing a ReplicationStrategy
that is akin to DistributionStrategy. The replication strategy allows a Java
instance be stored/updated in multiple slices as identical copies.
This is primarily to support quasi-static master data such as CoutryCode or
CurrencyCode, that are a) often referred by many other entities and b)
seldom updated. 

> Could we mark particular object relations to be unjoinable? So JPA would 
> not generate queries that try to join across the relation, thus allowing 
> slices to execute the multi-part query on the appropriate databases??

This will require a) special query processing and more importantly b)
establishing in-memory references from partial results obtained from
multiple slices. Currently, Slice supports neither. But the suggested
approach is viable. 



Fernando Padilla wrote:
> 
> So according to the documentation, Slices has a "Collocation Constraint" 
> (copied below).  Can the experts comment on this requirement?  Is there 
> any way to remove or ignore that requirement?  With extra code, or 
> enhancements to openjpa?  Or with accepting extra caveats?
> 
> I would like to have an object graph split across databases, and it 
> would be quite annoying (but doable) to cut up the object graph, via 
> storing object ids, instead of object references/relations... but that's 
> just a bit disappointing..
> 
> 
> Could we mark particular object relations to be unjoinable? So JPA would 
> not generate queries that try to join across the relation, thus allowing 
> slices to execute the multi-part query on the appropriate databases??
> 
> 
> 
> 
> 
> 
> 2.8. Collocation Constraint
> 
> No relationship can exist across database slices. In O-R mapping 
> parlance, this condition translates to the limitation that the closure 
> of an object graph must be collocated in the same database. For example, 
> consider a domain model where Person relates to Adress. Person X refers 
> to Address A while Person Y refers to Address B. Collocation Constraint 
> means that both X and A must be stored in the same database slice. 
> Similarly Y and B must be stored in a single slice.
> 
> Slice, however, helps to maintain collocation constraint automatically. 
> The instances in the closure set of any newly persistent instance 
> reachable via cascaded relationship is stored in the same slice. The 
> user-defined distribution policy requires to supply the slice for the 
> root instance only.
> 
> 

-- 
View this message in context: http://n2.nabble.com/Slices%2C-Collocation-Constraint-tp1377733p1400350.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.