skip to main content
Corticon Studio: Rule Modeling Guide : Writing Rules to access external data : Precondition and Filters as query filters : Filter Queries: Multiple Aliases
 

Try Corticon Now
Filter Queries: Multiple Aliases

Overview

When a Precondition/Filter expression contains multiple aliases, only a portion of the expression can be performed in the database. Because all Precondition/Filter expressions are conditions, their form is normally:
Left-hand side <comparison operator> Right-hand side
where left-hand side (LHS) and right-hand side (RHS) are comprised of some combination of an alias, attribute (or literal value) and operator. When multiple aliases are used, one alias is normally used on the LHS and another on the RHS. The following two tables show which of these aliases (if either) forms the basis of the Query Filter.
The tables below use the following abbreviations:
*QF – Query Filter
*DbP – The alias is configured as “Database Persistent” in the Vocabulary Editor. This setting is chosen by the technical integrator who mapped the Vocabulary to the connected external database.
*E2Db – The alias is extended to a database
*A1 – Any alias on the left-hand side of the Precondition/Filter expression
*A2 – Any alias on the right-hand side of the Precondition/Filter expression
*DbSCO – A database supported collection operator – see table of qualifying criteria above for complete list.
*EDbJQ – Refers to the com.corticon.reactor.EnableDatabaseJoinQueries property setting in CcStudio.properties(inside CcConfig.jar). By default, this property setting is false.

Associated Multiple Aliases

For expressions where the LHS and RHS aliases are associated (LHS alias is a parent of RHS alias, for example), the following table applies:
Table 9. Query Filters when Multiple Aliases are Associated
Associated
RHS Alias: A2
RHS Alias: A2
RHS Alias: A2
DbP
E2Db
Not DbP
LHS Alias: A1
DbP
No QF
If only DbSCO on A2: A2 forms QF
If only DbSCO on A1: A1 forms QF
Otherwise: no QF
No QF
LHS Alias: A1
E2Db
If only DbSCO on A1: A1 forms QF
If only DbSCO on A2: A2 forms QF
Otherwise: no QF
No QF
No QF
LHS Alias: A1
Not DbP
No QF
No QF
No QF

Independent Multiple Aliases

For expressions where the LHS and RHS aliases are independent (in other words, not associated), the following table applies:
Table 10. Query Filters when Multiple Aliases are Independent (not associated)
Independent
RHS Alias: A2
RHS Alias: A2
RHS Alias: A2
DbP
E2Db
Not DbP
LHS Alias: A1
DbP
No QF
If EDbJQ=true: A2 forms QF Otherwise: no QF
No QF
LHS Alias: A1
E2Db
If EDbJQ=true: A1 forms QF Otherwise: no QF
If EDbJQ=true: whichever alias appears first in the expression forms QF
If EDbJQ=true: A1 forms QF Otherwise: no QF
LHS Alias: A1
Not DbP
No QF
If EDbJQ=true: A2 forms QF Otherwise: no QF
No QF
An important caveat about the property settings: the execution sequence diagram reflects which expressions will get processed as Filter Queries if the Rulesheet where to be saved/regenerated using current Studio property settings. Configuration settings such as EnableDatabaseJoinQuery change the behavior of Studio’s compiler.
In other words, the execution sequence diagram doesn’t reflect the configuration under which the Rulesheet was last saved/regenerated. It reflects the current configuration of Studio. So it’s possible to see an expression appear as a Query Filter in an execution sequence diagram and then run a test and see that it wasn’t processed as a Query Filter because at the time the Rulesheet was saved one of these configuration settings was false.