skip to main content
Corticon Studio: Rule Modeling Guide : Rules containing calculations and equations : Datatype compatibility and casting : Defeating the parser
 

Try Corticon Now
Defeating the parser
The part of Corticon Studio that checks for data type mismatches (along with all other syntactical problems) is the Parser. The Parser exists to ensure that whatever is expressed in a Rulesheet can be correctly translated and compiled into code executable by Corticon Studio's Ruletest as well as by the Corticon Server. Because this is a critical function, much effort has been put into the Parser's accuracy and efficiency. But rule modelers should understand that the Parser is not perfect, and can't anticipate all possible combinations of the rule language. It is still possible to slip one past the Parser. Here is an example:
Figure 134. LHS and RHS Resolve to Integers
In the figure above, we see an assignment expression where both LHS and RHS return Integers under all circumstances. But making a minor change to the RHS throws this result into confusion:
Figure 135. Will the RHS Still Resolve to an Integer?
The minor change of adding a division step to the RHS expression has a major effect on the data type of the RHS. Prior to modification, the RHS always returns an Integer, but an odd Integer! When we divide an odd Integer by 2, a Decimal always results. The Parser is smart, but not smart enough to catch this problem.
When the rule is executed, what happens? How does the Corticon Server react when the rule instructs it to force a Decimal value into an attribute of type Integer? The server responds by truncating the Decimal value. For example if integer2 has the value of 2, then the RHS returns the Decimal value of 2.5. This value is truncated to 2 and then assigned to integer1 in the LHS.
When we focus on this rule here, alone and isolated, it's relatively easy to see the problem. But in a complex Rulesheet, it may be difficult to uncover this sort of problem. Your only clue to its existence may be numerical test results that do not match the expected values. To be safe, it's usually a good idea to ensure the LHS of numeric calculations has a Decimal data type so no data is inadvertently lost through truncation.