Slices, Collocation Constraint

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.

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-Collo...3p1400350.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.