<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 14/02/2011 09:30, Wolfgang Laun wrote:
<blockquote
cite="mid:AANLkTi=bodjpeTyi6-28g72qDDGVshz1CP4fYEz+4Y_c@mail.gmail.com"
type="cite"><a moz-do-not-send="true" id="d0e4493"
class="indexterm">Compare these three quotes from the current
Expert documentation:<br>
<br>
(1) Return Value restriction (...) must return results that do
not depend on time.<br>
</a><a moz-do-not-send="true" id="d0e4551">(2) An </a><a
moz-do-not-send="true" id="d0e4559" class="indexterm">inline
eval constraint (...) expression (...) expression must be
constant over time.<br>
(3) </a><a moz-do-not-send="true" id="d0e4735">[CE] Evals (...)
are (...) ideal (...) when functions return values that change
over time.<br>
</a></blockquote>
There are two aspects here. One was indexing. Field constraint are
potentially indexed, evals were not. For indexing to work the
evaluations must be time constant or the update and retract fails.<br>
<br>
Eval nodes have no joins and no indexing so they are safe from time
sensitive changes.<br>
<br>
Drools 4.0 implemented shadow facts in the same way that Jess did.
Further more Drools allows nested access access. When a modify or
retract was done if something had changed and the engine was not
aware of it, or a nested field changed, it effectively broke the
engine - modifies and retracts would not work. Eval was/is slightly
less immune from that.<br>
<br>
Drools 5.0 uses tree graph approach and now retracts will always
work and aren't sensitive to any data. Modifies can still
potentially be a problem as it can screw up indexing if you changed
a nested field without notifying the engine. Eval has no indexing,
so is not impacted by this.<br>
<br>
Mark<br>
<blockquote
cite="mid:AANLkTi=bodjpeTyi6-28g72qDDGVshz1CP4fYEz+4Y_c@mail.gmail.com"
type="cite"><a moz-do-not-send="true" id="d0e4735"><br>
Note that this appears to mean that the behaviour of (1) == (2)
!= (3).<br>
<br>
Many things can or must "change over time:" fact data, global
data, results of constructors such as new Date() or methods such
as System.currentTimeMillis().<br>
<br>
So what can I use in an Eval CE that cannot be used in a Return
Value or Inline Eval?<br>
<br>
Perhaps this is trying to convey some notion of caching for
constraints and the evaluation strategy for LHS, but then the
wording is insufficient. Let's make an experiment.<br>
<br>
Example 1:</a><a moz-do-not-send="true" id="d0e4735"> Given
these rules and one pair of facts A, B, which of the three rules
ab1, ab2, ab3 will fire after the last rule (a) fires? There are
8 possible answers. (You may notice that there is some
redundancy in each rule.)<br>
<br>
rule ab1<br>
when<br>
A( $va:va, $b: b ) eval( $va + $b.getVb() > 100 )<br>
B( this == $b, $vb: vb ) eval( $va + $vb > 100 )<br>
then<br>
System.out.println( "ab1: a+b > 100" ); <br>
end<br>
<br>
rule ab2<br>
when<br>
A( $va:va, $b: b , eval( $va + $b.getVb() > 100 ) )<br>
B( this == $b, $vb: vb, eval( $va + $vb > 100 ) )<br>
then<br>
System.out.println( "ab2: a+b > 100" ); <br>
end<br>
<br>
rule ab3<br>
when<br>
$a: A( $b: b , $va: va > ( 100 - $b.getVb() ) )<br>
B( this == $b, $vb: vb > ( 100 - $a.getVa() ) )<br>
then<br>
System.out.println( "ab3: a+b > 100" ); <br>
end<br>
<br>
rule a<br>
salience -10<br>
no-loop true<br>
when<br>
$a: A( $va: va ) <br>
$b: B( $vb: vb )<br>
then<br>
modify( $b ){ setVb( 200 ) }<br>
end<br>
<br>
Example 2: Now change the first line in the when parts according
to:<br>
ab1:<br>
</a><a moz-do-not-send="true" id="d0e4735"> A( $va:va, $b: b )<br>
ab2:<br>
</a><a moz-do-not-send="true" id="d0e4735">A( $va:va, $b: b
)</a><a moz-do-not-send="true" id="d0e4735"><br>
ab3: <br>
</a><a moz-do-not-send="true" id="d0e4735"> $a: A( $b: b )</a><a
moz-do-not-send="true" id="d0e4735"><br>
<br>
</a><a moz-do-not-send="true" id="d0e4735">Which of the three
rules ab1, ab2, ab3 will fire now after the last rule (a) fires?</a><a
moz-do-not-send="true" id="d0e4735"><br>
<br>
Wolfgang<br>
<br>
PS: Scroll down for the answers.<br>
<br>
v<br>
<br>
<br>
v<br>
<br>
<br>
v<br>
<br>
<br>
v<br>
<br>
<br>
v<br>
<br>
<br>
v<br>
<br>
<br>
v<br>
<br>
<br>
Example 1: None of the rules fires.<br>
Example 2: All three rules fire.<br>
<br>
<br>
</a>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>