[rules-users] Field value is different when and then section, very strange. Is it mvel vs java issue

[Davide Sottara]

When an object is insert in the working memory, it will be matched against
all rules: some of them will become active, because the logic expressed in
there applies to your fact, some others will not. 
So, Wolfgang has pointed out an important detail: make sure that there is a
strong logic correlation
(implication) between the conditions in the LHS and the actions in the RHS,
so that you don't execute 
unwanted actions.

Given the fact that evaluation and execution take place in two different
stages (see Esteban's email 
for details), a change in the object's status MAY invalidate the conditions,
but the engine needs to know about that: by the time a rule is executed, it
won't go back and double-check the conditions unless told so.

So (citing Greg this time): if your logic is sound, and you apply modify
appropriately, you should not get
into a loop - or, if you do get into a loop, it's because it's "necessarily"
imposed by the application logic
(I'm assuming that there are other external ways to control the loop
termination), for example:

rule "controlled loop"
when 
  $x : X( $n : val < 10 )
then
  modify ($x) { setVal( $n + 1 ); }
end

as opposed to:

rule "loop"
when 
  $x : X( $n : val  )
then
  modify ($x) { setVal( $n + 1 ); }
end

rule "breaker"
salience 10
when
 $x : X( val > 10 )
then
  retract( $x );
end


This said, there are cases when your same fact is shared between two
separate contexts:

rule "One of rules dealing with age"
when
  $p : Person( $a : age )
  $b : Birthday( person == $p )
then
  modify ($p) { setAge( $a+1 ); }
  ....
end

rule "One of rules dealing with salary"
when
  $p : Person( $s : salary < 100 )
then
  modify ($p) { setAge( $a+1 ); }
  ....
end

Here, it's not so evident which conditions should be added to prevent
unwanted interaction. Or, even
if you could, it would not be the best approach to mix the two business
logics...
In this case, there is a feature called *@propertyReactive* which I strongly
invite you to look up in the
manual AFTER you're feeling completely comfortable with the basic behaviour.
Best
Davide


p.a. drools.halt is only used in combination with fireUnitlHalt(), which
means that the engine will not
wait for an explicit command to fire the active rules. It's a global
behaviour that "shuts down" the
engine, so it's not recommended for loop control.



--
View this message in context: http://drools.46999.n3.nabble.com/Field-value-is-different-when-and-then-section-very-strange-Is-it-mvel-vs-java-issue-tp4020550p4020587.html
Sent from the Drools: User forum mailing list archive at Nabble.com.