This is a bug, manifest in all versions since 5.2.0. Actually it is a
"multibug", exhibiting a series of surprising inconsistencies.
* That null is silently ignored isn't documented (not for operators
'<' and '>').
* One might expect 0 to be used as the only reasonable default, but it isn't.
* One might any expression such as a < count < b involving a null
Integer 'count' to return false, but this isn't so either. One might
think that the default is "any integer in [a+1,b-1]" - but read on!
* Surprisingly, an expression with (count == null) such as 1 <
count < 1 or 10 < count < 1 will always fail, but 1 < count < 2
succeeds, although there is no integer that would ever make this
* One would really (REALLY!) expect that 1 < count < 100 and 1 <
count && count < 100 would always produce the same result, no matter
what the value of count is, but for null this isn't so.
* One would really expect that count <= Integer.MAX_VALUE would
always return true, given that it doesn't throw a NPE, but it returns
true for count == null. But, sure enough, Integer.MIN_VALUE <= count
<= Integer.MAX_VALUE always returns true.
In other words, if you have an Integer that might be null, always add
a test against null.
On 26/09/2012, mpgong <michael.p.gong(a)lmco.com> wrote:
I have a rule that looks something like this
$mydate : TaskRowDate(0 < currentLateCount < 100)
My problem is that currentLateCount is an Integer type because i want to be
able to store null. 0 means something different in my app.
The problem is when a fact that is inserted with the currentLateCount =
null, the above rule matches and is fired.
Is this suppose to be the case and what value does currentLateCount take
that makes it match?
View this message in context:
Sent from the Drools: User forum mailing list archive at Nabble.com
rules-users mailing list