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

Jamie jshaw at llbean.com
Thu Nov 10 12:23:53 EST 2011


Thanks for the feedback.

Wolfgang, that's a good thought, but we do need to do some re-evaluation
along the way - just not as much as we're doing right now - so the 'dirty
update' approach doesn't seem applicable here.

Robert, your post got me thinking.  If I'm interpreting what you're saying
correctly - Drools is smart enough to know which rules depend on which types
of objects in their LHS, so if you modify an object of a particular type,
only the rules that depend on that type get re-evaluated.  It seems
completely logical, but I hadn't thought about it that way.  Am I
understanding the mechanics correctly?

If so, I think we need to re-design our 'output' fact a bit.  It currently
contains several lists of codes - 2 lists for the order, 1 for the buyer,
and 1 for each of the recipients.  It's bound to a variable in the LHS of
nearly every rule and is updated in the RHS of a majority of them, which I
now realize is causing nearly every rule to be re-evaluated after the firing
of a majority of the rules.  As a result, performance deteriorates rapidly
as the number of facts grows.

I'm thinking that we should put the lists of suspect codes directly into the
facts that they're related to so that when a list is updated, only the rules
that care about that type of fact will get re-evaluated.  We'd get rid of
the 'output' fact altogether and instead, after the fireAllRules() call
completes, we'd iterate through all of the facts we put into the rules
engine and retrieve the lists of codes from each.

How does this approach sound?
  

--
View this message in context: http://drools.46999.n3.nabble.com/Preventing-re-evaluation-on-modification-of-output-fact-tp3455022p3497378.html
Sent from the Drools: User forum mailing list archive at Nabble.com.



More information about the rules-users mailing list