Closed 53A-1 closed 3 years ago
Yeah this looks like a bug. Thanks for reporting it, I'll look into it and see if I can get a solution in place.
Fixed in commit 5ca2c84d3ee63488ac31e6c524064de3f35aa72b. This was an issue due to a data type compatibility check within the equals and not-equals operators of the ast.ComparisonExpression
class. The equality operators should be able to work with any combination of data types.
The reason this worked when there was no type information is that the type would default to UNDEFINED which is considered to be compatible with anything.
Once the unit tests pass, I'll tag and release v3.1.1. Again thanks for reporting this.
Fixed in release 3.1.1 which is now on PyPi.
Great, thanks a million for the quick fix and rollout to PyPi!
The workarounds given in https://github.com/zeroSteiner/rule-engine/issues/13 do not work in case the types are provided:
This will produce an errors.EvaluationError('data type mismatch') Wouldn't it make sense to add a check whether
any
side is None to __op_arithmetic_values, i.e. aright after checking if both are None?
Working around this in Python by normalizing the input value is not an elegant option since it would require to typedef the values twice - once for the Rule Engine context and once for the normalization.
EDIT: Ok, worked around it using
rule.condition.context.resolve_type(mapping) == rule_engine.DataType.FLOAT
now, but it still seems adding the check to the library would make this task easier, albeit arithmetic operators are undefined for None.