15.2.7. Perspectives over model boundaries
What happens if we give a user role a perspective on a role in a context that is contained in an imported model? We can easily do so by either adding that role as a calculated role to our local context, or by specifying the object of the perspective with a query.
As a consequence, modifications made to the object of the perspective should be sent to our user role. But, and this is a big but, there may very well be modifying roles in the original model. They should have a perspective on our user role in order to be able to send their deltas to it – but this would reverse the dependency relation between the two models!
Figure 12. Crossing the border between an importing model (right) and its import. The dotted line between context C2 and role R indicates that R functions as a calculated role in C2. The dashed perspective line from role U1_in_Import to role U2 represents the perspective that is necessary for U2 to receive updates to R made by U1_in_Import.
Figure 12 shows us a model of this situation. On the left we find the model that is imported; on the right the model that imports. Now it is important to realize what happens when the importing model is created. It may refer back to contexts and roles in the import, as is shown with role R, that is added to context C2 as a calculated role. The query path that calculates it runs from C2 to X, to E, to C1 and then to R. This is a perfectly normal query.
The synchronization problem arises from the fact that user role U1_in_Import has a modifying perspective on R. When it modifies R, it should send deltas to U2 – but it can have no knowledge of U, as the imported model was written before the importing model!
We cannot even adapt the imported model, because it would then need to refer to a role in a model that imports it. This cannot be: the import relation between two models runs one way only.
15.2.7.1. Solution
We can solve this by adding perspectives in runtime to the imported model. This is not as crazy as it may seem; as a matter of fact, we routinely add inverted queries to imports as importing models are added to a PDR installation.
It is important, however, to understand that this only solves the problem when both the PDR installation whose user fills U1_in_Import, and the PDR installation whose user fills U2, have the importing model.
To make things easier, when you look at Figure 12, identify the part to the left of the double line with one PDR, the part on the right with another.
In other words, both peers must have the importing model. Otherwise either deltas will not even be sent (when the importing model is absent on the left), or no destination for them will be found (when the importing model is absent on the right).