[rules-users] Avoiding writing redundant rules

Earnest Dyke earniedyke at yahoo.com
Mon Jul 19 13:14:44 EDT 2010


A couple of things come to mind with regards to your "example solution":

1. Will there only ever be one Person in working memory that can match and 
trigger your first rule? If not, setting a single boolean will only indicate 
that the first rule has fired at least once, not for each Person, or one Person, 
or two... or whatever your requirement is.

2. I usually accomplish this with a place holder fact or a fact created as an 
extension of a, for example your Person, class. This also acts as a place 
holder.

I agree, I don't like having duplicated code that is just negated because as we 
know, negating a "simple rule" can turn out to be not such a simple thing to do.

Earnie!




________________________________
From: skasab2s <skasab2s at smail.inf.fh-brs.de>
To: rules-users at lists.jboss.org
Sent: Mon, July 19, 2010 12:57:39 PM
Subject: [rules-users] Avoiding writing redundant rules


Hello,

in our company we use DRL-files and we have the problem with the fact, that
rules have no 'else'-part. We've read in this forum, that we can simulate
the else-part of a rule by declaring a new rule which has the constraints of
the first rule, but  negated. We regard this as some kind of redundancy in
our code , besides our rule-files become twice as large and drools have to
evaluate the (almost) same constraints twice.

We wanted to ask you if it makes sense to declare additional variables in
order to mark if a rule has fired. Something like this:

<code>
declare FirstRuleHasFired
    value: boolean
end

...
//Insert an object from type  FirstRuleHasFired

...

rule "FirstRule" salience 100
   when 
      Person (name)
   then
  //do some job 
firstRuleHasFired.setValue(true) ;  
end 

rule "SecondRule" salience 90
   when 
      not(FirstRuleHasFired(value == true))
   then
  //do some other job
  )    
  ..
</code>

Or do you know some other useful tricks to avoid the redundancy I have
written about?

Thanks a lot for every idea and/or advice!

Regards,

skasab2s 
-- 
View this message in context: 
http://drools-java-rules-engine.46999.n3.nabble.com/Avoiding-writing-redundant-rules-tp979016p979016.html

Sent from the Drools - User 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/20100719/7dbb3bff/attachment.html 


More information about the rules-users mailing list