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.
