Store all rules with a unique id (rule id) and keep dates of when rules
were put in/out of production. Store your net matches in a database,
after a run, and you can easily pull the delta to show what didn't
"match" on a particular day.
[mailto:email@example.com] On Behalf Of jdepaul
Sent: Tuesday, April 17, 2007 1:57 PM
Subject: [rules-users] Tracking non-matches...
I was hoping for some opinions on the following:
Client will have many rules (about 1000) per RuleBase. The primary goal
is to assert Facts and find Matches in one or more rules. The secondary
goal may be to keep track of those Facts that did not produce Matches.
I was wondering what the best solution may be in this case?!
The benefit in keeping track of the non-matches would be periodic
analysis of the non-matches to discover patterns and perhaps provide
monitoring and notification. An additional benefit may be to spot a
and setup additional rules to reduce the number of non-matches.
So I would need to not only spot the no-match condition, I also need to
persist the no-match event in the database for tracking and later
One way I can see is to assert a new Match fact the instance a single
rule is matched and then test for the presence/absence of the Match()
Efficiency and speed are paramount in our case, so I'm wondering if
there is an alternate approach that would work here.
View this message in context:
Sent from the drools - user mailing list archive at Nabble.com
rules-users mailing list