[rules-users] Preventing re-evaluation on modification of 'output' fact

[Wolfgang Laun]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20111102/4660a438/attachment.html