openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <ppod...@apache.org>
Subject Re: Slices, Collocation Constraint
Date Thu, 30 Oct 2008 20:24:46 GMT

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.


Mime
View raw message