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

Try Corticon Now

Datatype compatibility and casting

An important prerequisite of any comparison or assignment operation is data type compatibility. In other words, the data type of the equation's LHS (the data type of A) must be compatible with whatever data type results from the evaluation of the equation's RHS (the data type of B). For example, if both attributes A and B are Decimal types, then there will be no problem assigning the Decimal value of attribute B to attribute A.
Similarly, a comparison between the LHS and RHS makes no real sense unless both refer to the same kinds of data. How does one compare orange (a String) to July 4, 2014 (a Date)? Or false (a Boolean) to 247.82 (a  Decimal)?
In general, the data type of the LHS must match the data type of the RHS before a comparison or assignment can be made. (The exception to this rule is the comparison or assignment of an Integer to a Decimal. A Decimal can safely contain the value of an Integer without using any special casting operations.) Expressions that result in inappropriate data type comparison or assignment should turn red in Studio.
In the examples that follow, we will use the generic Vocabulary from the Rule Language Guide, since the generic attribute names indicate their data types:
Figure 125. Generic Vocabulary used in the Rule Language Guide
The following figure shows a set of Action rows that illustrate the importance of data type compatibility in assignment expressions:
Figure 126. Datatype Mismatches in Assignment Expressions
Let's examine each of the Action rows to understand why each is valid or invalid.
A – this expression is valid because the data types of the LHS and RHS sides of the equation are compatible (they're both Boolean).
B – this expression is invalid and turns red because the data types of the LHS and RHS sides of the equation are incompatible (the LHS resolves to a DateTime and the RHS resolves to a String).
C – this expression is invalid and turns red because the data types of the LHS and RHS sides of the equation are incompatible (the LHS resolves to a String and the RHS resolves to a DateTime).
D – this expression is valid because the data types of the LHS and RHS sides of the equation are compatible even though they are different!  This is an example of the one exception to our general rule regarding data type compatibility: Decimals can safely hold Integer values.
E – this expression is invalid and turns red because the data types of the LHS and RHS sides of the equation are incompatible (the LHS resolves to a Boolean and the RHS resolves to a Decimal). Here, the tool tip provides essentially the same information.
Note that the Problems window contains explanations for the red text shown in the Rulesheet.
The following figure shows a set of Conditional expressions that illustrate the importance of data type compatibility in comparisons:
Figure 127. Datatype Mismatches in Comparision Expressions
Let's examine each of these Conditional expressions to understand why each is valid or invalid:
a – This comparison expression is valid because the data types of the LHS and RHS sides of the equation are compatible (they're both Strings). Note that Corticon Studio confirms the validity of the expression by recognizing it as a comparison and automatically entering the Values set {T,F} in the Values column.
b – This comparison expression is invalid because the data types of the LHS and RHS sides of the equation are incompatible (the LHS resolves to a String and the RHS resolves to a DateTime). Note that, in addition to the red text, Corticon Studio emphasizes the problem by not entering the Values set {T,F} in the Values column.
c – This comparison expression is invalid because the data types of the LHS and RHS sides of the equation are incompatible (the LHS resolves to a Boolean and the RHS resolves to a Decimal).
d – This comparison expression is valid because the data types of the LHS and RHS sides of the equation are compatible. This is another example of the one exception to our general rule regarding data type compatibility: Decimals may be safely compared to Integer values.
e – This comparison expression is valid because the data types of the LHS and RHS sides of the equation are compatible. Like example 4, this illustrates the one exception to our general rule regarding data type compatibility: Decimals may be safely compared to Integer values. Unlike an assignment, however, whether the Integer and Decimal types occupy the LHS or RHS of a comparison is unimportant.
* Datatype of an expression
* Defeating the parser
* Manipulating datatypes with casting operators