9.2.2. Backward compatibility with respect to user data
Up till now, we’ve only discussed compatibility of models. What about compatibility of a model and data? In Perspectives, data consists of context and role instances (collectively called resources). Obviously, resources that are constructed with respect to a particular model version cannot - indeed, should not! - cause problems. However, a new model version’s types might not fit existing data.
Let’s first examine what kind of problems can arise in this relation.
Resources turn out to be remarkably resilient with respect to types. First of all, notice that the shape of context and role instances does not depend on their type. This means that no problems can arise in encoding and decoding data when it is moved in and out of the database. In other words, the infamous problem of schema evolution does not arise in the context of Perspectives with respect to the database it makes use of.
9.2.2.1. Backward compatibility of role instances
How can a role type change?
A role type can
-
acquire or lose a property
-
have the type of a property change
-
have the allowed type of its binding change
-
acquire or lose a aspect
-
change into another kind (kinds are user, context, thing)
-
acquire or lose a view
-
change its cardinality (functional or not)
-
become indexed or no longer indexed
-
become linked or no longer linked
Some of these changes will cause the PDR to throw runtime errors in combination with existing representations of the instances of the type. We’ll discuss each of them in turn.
Losing or acquiring a property
This causes no runtime trouble. A new property will, in time, lead to values be represented on role instances. Existing values represented on role instances will simply never be used.
Change the type of a property
This will cause problems for some types, depending on the change. As a String type is not interpreted, a change to that type is frictionless. However, change to Boolean, Number or Date may invalidate some existing string values. Errors would arise on interpreting a string representation as a typed value.
This can be detected automatically by comparing the new model version to the old model version.
We can prevent runtime errors automatically, too, by removing property values whose type has acquired an incompatible change.
Change the allowed type of a role type binding
If the new type is more general than the old type, no problems arise. Otherwise, some existing bindings may be invalid. This mostly boils down to 1, as properties are expected that are not represented. It may happen that the more specialised type shadows an existing property that has another type. This, however, will be detected by the model checker: it is a model time error.
Acquire or lose an aspect
This reduces to 1.
Change into another kind
This would be a huge semantic change. However, there seem to be no runtime errors that can arise because of such a change.
Acquire or lose a view
There can be no runtime errors as a consequence of such a change.
Change of cardinality
There can be no problem if a role no longer is functional. A role that becomes functional will give unforeseeable semantic effects, but there will be no runtime errors. There is no automatic way to fix this semantic problem. In the end, the user should select which of the role instances in a context should be selected as the one that may continue to be present.
Become indexed, or become not indexed
An indexed role is by definition functional. It means that we can refer in model texts to this role instance by a fixed name. Internally, this name is changed into a unique name for each end user. So, while references in the model text must change, there is no consequence for the runtime.
Become linked or unlinked
As a role becomes unlinked, the context instances that hold that role will no longer use the indices stored within them to retrieve the instances of the roles. This causes no particular problems.
However, the other way round is problematic. Without further action, each context instance would lose its role instances for the particular type. This problem can be fixed automatically.
Nevertheless, no runtime errors would occur.
Wrapping up: compatibility of role instances
We first notice that runtime errors only will occur for 2, property types that change their range type. Can such problems be diagnosed before models are put into use? Yes, but only by comparing a new model version with its predecessor. Such a check is really straightforward.
Second, we should notice that semantic errors may arise, too, in cases 7 and 9.
9.2.2.2. Backward compatibility of context instances
As with roles, let’s explore the ways in which a context type can change.
A context type can
-
change its kind
-
lose or acquire aspects
-
lose or acquire roles, where we must distinguish user roles from context roles and thing roles
-
lose or acquire nested context types
-
move to another context type
-
become indexed or become not indexed
Change the kind of a context
Context kinds come in flavours like Domain, Party, Case, Activity and State. There are semantic restrictions on embedding context kinds in other context kinds. However, these are not yet checked. Anyway, these are model issues only.
Lose or acquire aspects
This reduces to losing or acquiring roles.
Lose or acquire roles
The situation is very similar to roles losing or acquiring properties. Again, this causes no runtime problems, in general terms. Role instances that are represented on context instances that have a type that is no longer modelled for that context, just are ignored, runtime.
There is one exception to this rule and that concerns user roles. When a user role is removed, it may be that a particular context instance refers to an instance of that role that represents the end user in that context. This value may no longer be used (as it no longer has a type!). However, just ignoring it means that the end user no longer has access to the context. This obviously is a big semantic problem. But, without handling it properly, there will be runtime errors, too.
Runtime errors can be prevented by automatic action (remove the me member from affected contexts).
Lose or acquire nested context types.
This is not a runtime problem. The consequence is that type names change; this should be handled in model time and such changes should be transparent in runtime.
Move to another context type
This is the same issue as 4, but now viewed from the other side.
Become indexed or become not indexed
As with roles, this is not a runtime problem.
Wrapping up: compatibility of context instances
We see only one issue for run time and that is 3, when a context loses a user role type. However, this problem can be handled automatically.
9.2.2.3. Conclusion: backward compatibility of user data
Based on this analysis, we will say that data is compatible with an updated model version, if and only if it causes no runtime errors.
If the updated model version requires changes to the data that can be performed automatically, we say that the data is fixable with respect to the new model version.
Existing data (created with a particular model version) may turn out to be either compatible or fixable with respect to a new version of that model. Remember that this applies just to the issue of runtime errors, not to semantic issues!