As we have seen throughout this manual, the concept of scope is key to any solid understanding of rule design and execution. Scope in a rule helps define or constrain which data is included in rule processing, and which data is excluded. If a rule uses the Vocabulary term FlightPlan.cargo.weight then we know that those FlightPlan entities without associated Cargo entities will be ignored. How can we act upon a FlightPlan.cargo.weight if the FlightPlan doesn’t have an associated cargo? Obviously we can’t – and neither can Corticon Studio or Server.
But we also know that Vocabulary root-level entities – FlightPlan, for example – bring every instance of the entity into scope. This means that a rule using root-level FlightPlan acts on every instance of FlightPlan, including Cargo.flightPlan, Aircraft.flightPlan, or any other role using FlightPlan that may exist in our Vocabulary.
When we add the ability for the Corticon Server and Studio to dynamically retrieve data from a database, rule scope determines which data to retrieve. This is exactly the same concept as Studio determining which data in an Input Ruletest to process and which to ignore based upon a rule’s scope. So if we write rules using root-level FlightPlan, then the Studio will process all FlightPlans present in the Input Ruletest during rule execution.
But with EDC's Direct Database Access, the amount of test data is no longer limited to that contained in a single Input Ruletest – it is limited by the size of the connected database. Rules using root-level FlightPlan (or any other root-level entity) will force the Server or Studio to retrieve ALL FlightPlan entities (records) from the database. If the database is very large, then that will mean a large amount of data is retrieved. For this reason, database access for root-level rules is turned off by default. This ensures that we do not accidentally force the Server to perform extremely large and time-consuming data retrievals from the database unless we explicitly require it.
