4.3. Queries
A screen programmer can only make a client proceed step by step through the network, but a modeler may create a query that performs any number of steps with a single request. Such queries are stored as Calculated Roles or Calculated Properties. Incidentally, these calculated roles can be requested by a client, just like other roles and properties.
If we remove a context, how do we detect (in order to recompute) queries that have passed through that context? In general, how do we detect the queries that should be recomputed after any of the atomic changes that can be made to the network?
4.3.1. Queries trace their steps
The query execution engine records each step of a query. It saves the identification of the client request with the (function) type of each step, permitting the PDR to re-compute the request if the node visited by one of these steps is affected by a change to the underlying network.
Let’s look at the details of saving a query step. A step consists of the identification of a node, and the name of the step. This works out differently for the various steps.
| Step type | Node identification | Step name |
|---|---|---|
binding |
role identifier |
“model:System$Role$Binding” |
binder |
role identifier |
Role Type |
context |
role identifier |
“Model:System$Role$Context” |
role |
context identifier |
Role Type |
property |
role identifier |
Property Type |
Actually, we do not record the context step. See Deleting a role instance for an explanation.
The binding and context steps use a generic step name; for the other steps, we use role or property type names.
Now let’s look at what happens when changes are made to the network.