[rules-users] Inadvertant type conversion while using keyword "in"
We ran into an issue when evaluating string values against a list of values
while using the keyword "in".
We find that when there is a decimal place in the string value and either
the fact inserted into the session or the string values in the list end with
a zero, the string will be truncated, as if it were being type converted
from a string to an int.
As as example: Fact type "Test"
package com.sample;
public class Test {
private String code;
public String getCode() {
return code;
}
public void setCode(String code) {
this.code = code;
}
}
Sample DRL:
package com.sample
//Test code value == "1.5"
rule "Incorrect Execution"
when
Test($code : code in ("1.50"))
then
System.out.println("Unexpected execution: 1.50, 2.50 - actual code
value: 1.5");
end
//Test code Value == "1.5"
rule "Correct Execution"
when
Test(code == "1.5")
then
System.out.println("Expected execution - Code compared values: 1.5,
2.5 - actual code value: 1.5");
end
We insert a "Test" fact into the session with a code value of 1.5. The
output is as follows:
Unexpected execution: 1.50, 2.50 - actual code value: 1.5
correct execution - Code compared values: 1.5, 2.5 - actual code value: 1.5
Drools Expert documentation states:
Type coercion is always attempted if the field and the value are of
different types; exceptions will be thrown if a bad coercion is attempted.
For instance, if "ten" is provided as a string in a numeric evaluator, an
exception is thrown, whereas "10" would coerce to a numeric 10. Coercion is
always in favor of the field type and not the value type:
Both evaluators are actually syntactic sugar, internally rewritten as a list
of multiple restrictions using the operators != and ==.
Is there some way to disable the auto-conversion feature?
--
View this message in context:
http://drools.46999.n3.nabble.com/Inadvertant-type-conversion-while-using...
Sent from the Drools: User forum mailing list archive at Nabble.com.