It should be even more efficient to do what I call "dirty update". According to the
rule design pattern using this technique, you 
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.

HTH
Wolfgang


On 1 November 2011 23:25, Robert Crawford <crawford@kloognome.com> wrote:
Have you considered making the reasons for being suspicious objects in their
own right and inserting them independently? Let's say:

SuspectedFraudReason (abstract parent class)
TransactionsTooOften (extends SuspectedFraudReason)
TransactionsTooHigh (extends SuspectedFraudReason)

then indicate the reasons by inserting a new instance of an object, rather
than modifying your results object. If you have rules that depend on other
indicators of fraud, then they only get evaluated when that particular class
of SuspectedFraudReason is inserted, rather than every time you modify the
results object.

At the end, you can use a query() to collect all the reasons.



--
View this message in context: http://drools.46999.n3.nabble.com/Preventing-re-evaluation-on-modification-of-output-fact-tp3455022p3472137.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