Re: [rules-users] Preventing re-evaluation on modification of 'output' fact
It should be even more efficient to do what I call "dirty update".
According to the
rule design pattern using this technique, you
- add a "wrapper" fact with a pointer to the central (order) fact and a
field of some collection type
- 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
- 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.
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(a)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-modificatio...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Attachments:
- attachment.html (text/html — 2.6 KB)