Query
This section present queries.
Predicate
This section present the query predicates. (aka what you can put on the left hand side of rules).
Variables
Query variables are variables declared in a query. They are either explicitly (in a declaration) or implicitly declared. To be used manually, the variable need to be given an identifier. Indeed, all node pattern declare a query variable, used in the pattern matching, but only the one with an identifier are accessible manually.
The query variables are available in both the scope of the query where they are declared, and in the the scope of the statement this query belongs. In the case of rule statement, the variables are available in the production. In the case of an query expression, the variables are available in the rest of the statement.
Context
The notion of context in the rule-based paradigm refers to some structure which has to exist within the current host structure and which is related in some way with the match, but which is not replaced on rule application. Thus, in a query, marking context on some predicate enable to use these patterns to match and ensure that the Nodes bounded by these patterns will not be removed or replaced.
Context is marked by asterisked parenthesis: (* and *). These are the same symbols used for declaring query expressions, but the two concepts are different.
Query expression
A query can be used as an expression if it is enclosed in asterisked parentheses (* and *). Theses symbols are also used to declare context in a query but the concept is different. A query expression enables to execute the query in an imperative context (e.g. in a java block). Thus, the query can be used combined with other imperative statements (e.g. methods, aggregators, …). The query expression is a Node generator and can be used as such.
Query expressions finds all matches of the pattern and yields the currently bound value of the right-most non-bracketed node pattern.
Extent visibility
When looking for matches, queries only consider Node that are in their set of visible extents.
An extent collects its nodes not by a single list, but by a number of (doubly linked) lists. Currently, 16 lists are used, but this can easily be changed. This feature is used to partition the extents. The 16 lists are called the extent indexes.
Extents are used by the query graph to access the nodes of the graph. In this process, nodes can be “hidden” to queries by being on a extent index non visible by the query scope (see RGG's extent index visibility). Non visible nodes are not visited and “ignored” by the queries, they are not visited at all (thus, efficient to speed up queries). For the RGG model graph, queries use only the seven first indexes by default. The default index usage is:
- 0 to 6: Default visibility - used by default in queries. Only these indexes are visible by default.
- 7: Meta data index.
- 8: Type graph data - used for the multi-scales.
- 9 to 15: Unused indexes - non visible by default.
Note: the index visibility is not used for the display. Thus, nodes on a “non” visible index are still displayed in the 3d view.