It should be even more efficient to do what I call "dirty update". According to the<br>rule design pattern using this technique, you <br><ul><li>add a "wrapper" fact with a pointer to the central (order) fact and a field of some collection type</li>
<li>run the rules detecting various reasons and add an object to the collection, either such as Robert proposes or an enum, without calling modify/update on the wrapper<br></li><li>add a low-salience rule triggering just on the wrapper, which can easily determine whether the order is "healthy" or not, and do all the required clean-up.</li>
</ul>Of course, the current rule structure you have may make it difficult to follow these lines. As an alternative to low-salience, consider changing the focus after the 1st fireAllRules has run out.<br><br>HTH<br>Wolfgang<br>
<br><br><div class="gmail_quote">On 1 November 2011 23:25, Robert Crawford <span dir="ltr"><<a href="mailto:crawford@kloognome.com">crawford@kloognome.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Have you considered making the reasons for being suspicious objects in their<br>
own right and inserting them independently? Let's say:<br>
<br>
SuspectedFraudReason (abstract parent class)<br>
TransactionsTooOften (extends SuspectedFraudReason)<br>
TransactionsTooHigh (extends SuspectedFraudReason)<br>
<br>
then indicate the reasons by inserting a new instance of an object, rather<br>
than modifying your results object. If you have rules that depend on other<br>
indicators of fraud, then they only get evaluated when that particular class<br>
of SuspectedFraudReason is inserted, rather than every time you modify the<br>
results object.<br>
<br>
At the end, you can use a query() to collect all the reasons.<br>
<font color="#888888"><br>
<br>
<br>
--<br>
View this message in context: <a href="http://drools.46999.n3.nabble.com/Preventing-re-evaluation-on-modification-of-output-fact-tp3455022p3472137.html" target="_blank">http://drools.46999.n3.nabble.com/Preventing-re-evaluation-on-modification-of-output-fact-tp3455022p3472137.html</a><br>
Sent from the Drools: User forum mailing list archive at Nabble.com.<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</font></blockquote></div><br>