<!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 15:12, Mark Proctor wrote:
<blockquote cite="mid:4D594647.2000301@codehaus.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
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>
</blockquote>
I would add that currently no version of Drools indexes nested
fields constraints. So you aren't seeing the problem above with
regards to indexing and changes of nested fields. It really was more
of a future concern, to make sure your code doesn't break as the
engine progresses. I've just got indexing working for nested
accessors in Drools 5.2 so if anyone is changing nested accessors
and not notifying the engine, that will now be broken :)<br>
<br>
Mark<br>
<blockquote cite="mid:4D594647.2000301@codehaus.org" type="cite"> <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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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>
<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>