You are using 5.2.0?
I don't think that the *greatly simplified* version of your problem fails the way you described.
However: https://issues.jboss.org/browse/JBRULES-3111 describes a very similar issue, a severe regression from 5.1.1.
-W
Apologies if this has been addressed elsewhere: I couldn't find anything
quite like my issue.
My (greatly simplified and completely made-up) example:
Let's say I have this java class:
public class BaseballPitcher
{
public String getName();
public boolean isRightHanded();
public boolean isKnuckleBaller();
}
Multiple instances of this class are created with a variety of combinations
for the name and two boolean parameters.
Now I have a rule:
rule "Match pitchers: righties or knuckle-ballers"
when
$kbPitcher1 : BaseballPitcher($name: name, $righty: rightHanded == true
||
$knuckleballer: knuckleBaller == true)
$kbPitcher2: BaseballPitcher(name != $name, rightHanded == $righty,
knuckleBaller == $knuckleballer)
then
// Do something with these two pitchers $kbPitcher1 and $kbPitcher2
end
I am getting the curious result that this rule fires its conclusion when
$kbPitcher1 is in fact NEITHER right-handed nor a knuckle-baller (i.e.
rightHanded == false && knuckleBaller == false).
I've worked around this by changing the first condition in either of the
following two ways:
*// eval() the condition*
$kbPitcher1 : BaseballPitcher($name: name, $righty: rightHanded,
$knuckleballer: knuckleBaller,
*eval(isRightHanded() == true || isKnuckleBaller() == true)*)
...or....
*// bind the variables before checking values*
$kbPitcher1 : BaseballPitcher($name: name, $righty: rightHanded,
$knuckleballer: knuckleBaller,
*rightHanded == true || knuckleBaller == true*)
Does this make sense? Both are easy workarounds, and I believe the second
option (i.e. the one NOT using the eval) is the better solution from a
performance perspective, allowing the engine to index the these facts rather
than dynamically evaluate the condition every time.
But I'm a little surprised the first approach didn't work. Any ideas why
not?
--
View this message in context: http://drools.46999.n3.nabble.com/Unexpected-variable-binding-behavior-and-conditional-logic-tp3183355p3183355.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users