12.4.3. Linked and non-linked connections
As stated above in A refresher: structural connections in Perspectives, each connection is represented by two links so we can traverse connections in both directions. We left unsaid that there is an asymmetry in numbers: a single context can have many role (instances), but each role instance has just a single context. Similarly, a single role is filled by just one other role, but each role can fill an unlimited other number of roles. So, the cardinality of each connection is 1 to n.
There may be use cases where directly indexing (linking) all role instances in a context, or directly indexing all filled roles, becomes impractical. Consider, for example, a witnessing service where a single witness is involved in millions of financial transactions. Clearly, we should not require the PDR of this witness to load as a single entity these millions of references! Similarly, for the other kind of connection, think of a model repository where many thousands of users want to have a role in a particular model context, as end users that want to be notified of updates.
Instead, we want to be able to represent some links with a database query. To find all roles filled by role X is conceptually straightforward and, indeed, it is the type of query that every database system is optimised for. We will call such links Database Query Links (DQL).
12.4.3.1. Accessing DQLs
Traversing the connection between roles in the direction of the filled roles would occur, in Perspectives, in the form of a Calculated role that has the keywords filled by in its definition (a path query). As the typical use case for a DQL involves high volumes, it is desirable to limit the number of responses that come from the database. This is usually done by deploying two different techniques:
-
paging, i.e. retrieving a set of consecutive results on user demand;
-
filtering, i.e. just returning results that conform to some criterium
or a combination of both.
We can envision paging keywords as an extension of the Perspectives Query Language. Role properties would parameterize the paging query.
Similarly, we can conceptualise a different compilation of the existing filter expression, where the criterium would translate to a query carried out on the server. This is a well-defined, albeit possibly complex technical extension of PQL.