bump...
Anyone have some thoughts on whether my revise approach makes sense?
--
View this message in context:
http://drools.46999.n3.nabble.com/Preventing-re-evaluation-on-modification-of-output-fact-tp3455022p3509609.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
What you wrote sounds fine.
Having a sort of root object where List fields contain Odds and Ends, and
some rules rely on Odds (but not Ends) being updated and others that don't
it's not a good approach to make root a pattern in each rule.
It's like information hiding: A rule working with Odds
Thanks for the feedback. When we find the time to implement these changes,
I'll report back and let you know how they turned out.
--
View this message in context:
http://drools.46999.n3.nabble.com/Preventing-re-evaluation-on-modification-of-output-fact-tp3455022p3510471.html
Sent from the
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
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
I've continued digging in this issue and I've learned a few more things:
- Per a suggestion I received via the mailing list, I tried making the
'output' fact a global. This gave me an incredible performance boost -
going from 10 mins to 100 ms!
- BUT - making the output fact a global caused
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
Define FraudResultsDTO as a global. That way, you don't have to specify it in
the WHEN part merely for assigning a variable to it
- Original Message -
From: Jamie [js...@llbean.com]
Sent: 10/26/2011 09:24 AM MST
To: rules-users@lists.jboss.org
Subject: [rules-users] Preventing re
