What about Agenda Groups? Rule "pick group X" when Fact( attribute = "condition1" ) then drools.setFocus("Group X") end Rule "pick group Y" when Fact( attribute = "condition2" ) then drools.setFocus("Group Y") end Rule "Group X1" Agenda Group "Group X" when Smurf( ) then // Do something end Rule "Group X2" Agenda Group "Group X" when Smurfette( ) then // Something else end etc ------------------------------ *From:* rules-users-bounces(a)lists.jboss.org [mailto: rules-users-bounces(a)lists.jboss.org] *On Behalf Of *Jai Vasanth *Sent:* 31 January 2008 19:45 *To:* rules-users(a)lists.jboss.org *Subject:* [rules-users] Grouping rules Hi, I am building a system where I would need to fire different sets of rules based on some attribute in the fact object. Here are someways which I thought of, I was wondering if there was something better than that. 1) I could do this by creating different sessions based on the data attrbute (different sessions would have different rule packages based on the attribute) or 2) Have all the rules fire (all the different sets of rules) irrespective of the attribute and have them insert fact new objects into the working memory. In the second round of rules, collect the (newly made) fact objects based on the attribute and take that action. Thanks Jai _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Excuse me if you already understand but there is a difference between rule patterns being evaluated and their consequence running. Rules LHS are evaluated when objects are inserted into working memory whereas the consequence fires when you call fireAllRules(); The rules whose activations are executed are those in the given Agenda Group; thereafter those not in any agenda group execute. So if all rules are in an Agenda Group you should be OK. Of course they don't prevent all rule patterns from being checked as objects are inserted into WM (which has a performance impact) but this is what the RETE network was designed to optimise. You could try another configuration (but I think Agenda Groups are probably the preference by design). This gives complete isolation - but I haven't tried it so it might not even be possible ;-) global WorkingMemory wm; global RuleBase rbX; global RuleBase rbY; rule "Group X" when Fact( attribute == "condition1" ) then wm = rbX.newStatefulSession(); wm.fireAllRules(); end rule "Group Y" when Fact( attribute == "condition2" ) then wm = rbY.newStatefulSession(); wm.fireAllRules(); end Good luck. Mike ------------------------------ *From:* rules-users-bounces(a)lists.jboss.org [mailto: rules-users-bounces(a)lists.jboss.org] *On Behalf Of *Jai Vasanth *Sent:* 01 February 2008 15:07 *To:* Rules Users List *Subject:* Re: [rules-users] Grouping rules Thanks for responding Yes, I did consider agenda groups, but I thought agenda groups only ordered execution in a particular fashion, so if Rule "pick group X" fires then it would make sure that rules in Agenda Group X fire first before the remaining but the remaining would fire eventually. Is my understanding correct ? I am looking for a solution for completely isolating a rule set conditioned on an object attribute. On Feb 1, 2008 12:46 AM, Anstis, Michael (M.) <manstis1(a)ford.com&gt; wrote: > What about Agenda Groups? > > Rule "pick group X" > when > Fact( attribute = "condition1" ) > then > drools.setFocus("Group X") > end > > Rule "pick group Y" > when > Fact( attribute = "condition2" ) > then > drools.setFocus("Group Y") > end > > Rule "Group X1" > Agenda Group "Group X" > when > Smurf( ) > then > // Do something > end > > Rule "Group X2" > Agenda Group "Group X" > when > Smurfette( ) > then > // Something else > end > > etc > > ------------------------------ > *From:* rules-users-bounces(a)lists.jboss.org [mailto: > rules-users-bounces(a)lists.jboss.org] *On Behalf Of *Jai Vasanth > *Sent:* 31 January 2008 19:45 > *To:* rules-users(a)lists.jboss.org > *Subject:* [rules-users] Grouping rules > > Hi, > > > I am building a system where I would need to fire different sets of > rules based on some attribute in the fact object. > > Here are someways which I thought of, I was wondering if there was > something better than that. > > 1) I could do this by creating different sessions based on the data > attrbute (different sessions would have different rule packages based on the > attribute) > > or > > 2) Have all the rules fire (all the different sets of rules) > irrespective of the attribute and have them insert fact new objects into the > working memory. In the second round of rules, collect the (newly made) fact > objects based on the attribute and take that action. > > > > Thanks > > Jai > > > > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

The answer is not simple. :) All the alpha constraints are evaluated at fact assertion time, does not matter if they are early or late in the pattern order. Although, alpha constraints are usually quite cheap, since they are constraints that do not depend on other facts. Example: Person( name == 'bob' ) "name == 'bob'" is a literal constraint and do not depend on any other pattern (so it is an alpha constraint) and will be evaluated at assert time, does not matter the order in which patterns are written down. Beta constraints are constraints that depend on previous patterns and will only be evaluated when previous patterns are matched. Example: when Person( $likes : likes ) Cheese( type == $likes ) then end It is obvious in the previous example that "type == $likes" depends on the value of $likes that is a variable bound in a previous pattern (so it is a Beta constraint). It will only be evaluated if ALL previous patterns match. "from" CE is a special case of beta "node", that is only evaluated when all previous patterns match. []s Edson 2008/2/6, Anstis, Michael (M.) <manstis1(a)ford.com&gt;: > > Great news! > > Is this specific to the use of "from" whereas another rule like:- > > rule "avoid expense" > when > ControlFact( phase == "do expensive call" ) > AnotherFact( someExpensiveTimeConstantFunctionCall == someValue > ) > then > // Do something > end > > Could not have the LHS not evaluated or (to avoid a double negative), > would always have the LHS fully evaluated ;-) > > ------------------------------ > *From:* rules-users-bounces(a)lists.jboss.org [mailto: > rules-users-bounces(a)lists.jboss.org] *On Behalf Of *Edson Tirelli > *Sent:* 06 February 2008 12:29 > *To:* Rules Users List > *Subject:* Re: [rules-users] Grouping rules > > > Yes, it is possible to prevent the evaluation of part of the LHS > patterns by the use of previous constraints and/or the introduction of > control facts. > > For instance: > > rule "avoid expense" > when > ControlFact( phase == "do expensive call" ) > AnotherFact( ) from someExpensiveServiceCall > then > // Do something > end > > In the above example, the "someExpensiveServiceCall" will only be > executed when the previous patterns are matched, i.e., when phase > attribute of the ControlFact has the value "do expensive call". > > []s > Edson > > 2008/2/6, Anstis, Michael (M.) <manstis1(a)ford.com&gt;: > > > > I'm not sure as LHS's are evaluated when facts are inserted not when > > fireAllRules (or execute) is called. > > > > You can prevent the RHS from activating by using (for lack of a better > > name) "flag facts" (but this doesn't solve your problem); for example:- > > > > rule "avoid expense" > > when > > not exists Flag() > > AnotherFact( ) from someExpensiveServiceCall > > then > > // Do something > > end > > > > Don't forget though that if you share LHS patterns across multiple > > rules they will share the same nodes in the RETE network, so although you > > might be aware that the expensive calls are not required for some rules they > > might be required for other rules and hence you'll need to perform the > > expensive call when the facts are inserted in order for the other rules to > > activate. Perhaps if you better describe your use-case there might be a > > better solution. > > > > With kind regards, > > > > Mike > > > > ------------------------------ > > *From:* rules-users-bounces(a)lists.jboss.org [mailto: > > rules-users-bounces(a)lists.jboss.org] *On Behalf Of *Jai Vasanth > > *Sent:* 05 February 2008 19:35 > > *To:* Rules Users List > > *Subject:* Re: [rules-users] Grouping rules > > > > I had another question on these lines. Is there a way to preven even > > the LHS from evaluating for certain cases ? A few of my LHS computation > > involve some expensive service calls and I would like to avoid unless and > > until it is asolutely necessary. > > > > Thanks > > > > Jai > > > > On Feb 1, 2008 8:35 AM, Jai Vasanth <jaivasanth(a)gmail.com&gt; wrote: > > > > > Thanks. That helped. > > > > > > > > > On Feb 1, 2008 7:31 AM, Anstis, Michael (M.) <manstis1(a)ford.com&gt; > > > wrote: > > > > > > > Excuse me if you already understand but there is a difference > > > > between rule patterns being evaluated and their consequence running. > > > > > > > > Rules LHS are evaluated when objects are inserted into working > > > > memory whereas the consequence fires when you call fireAllRules(); > > > > > > > > The rules whose activations are executed are those in the given > > > > Agenda Group; thereafter those not in any agenda group execute. So if all > > > > rules are in an Agenda Group you should be OK. > > > > > > > > Of course they don't prevent all rule patterns from being checked > > > > as objects are inserted into WM (which has a performance impact) but this is > > > > what the RETE network was designed to optimise. > > > > > > > > You could try another configuration (but I think Agenda Groups are > > > > probably the preference by design). This gives complete isolation - but I > > > > haven't tried it so it might not even be possible ;-) > > > > > > > > global WorkingMemory wm; > > > > global RuleBase rbX; > > > > global RuleBase rbY; > > > > > > > > rule "Group X" > > > > when > > > > Fact( attribute == "condition1" ) > > > > then > > > > wm = rbX.newStatefulSession(); > > > > wm.fireAllRules(); > > > > end > > > > > > > > rule "Group Y" > > > > when > > > > Fact( attribute == "condition2" ) > > > > then > > > > wm = rbY.newStatefulSession(); > > > > wm.fireAllRules(); > > > > end > > > > > > > > Good luck. > > > > > > > > Mike > > > > > > > > ------------------------------ > > > > *From:* rules-users-bounces(a)lists.jboss.org [mailto: > > > > rules-users-bounces(a)lists.jboss.org] *On Behalf Of *Jai Vasanth > > > > *Sent:* 01 February 2008 15:07 > > > > *To:* Rules Users List > > > > *Subject:* Re: [rules-users] Grouping rules > > > > > > > > > > > > Thanks for responding > > > > Yes, I did consider agenda groups, but I thought agenda groups > > > > only ordered execution in a particular fashion, so if Rule "pick group X" > > > > fires then it would make sure that rules in Agenda Group X fire first before > > > > the remaining but the remaining would fire eventually. Is my understanding > > > > correct ? > > > > I am looking for a solution for completely isolating a rule set > > > > conditioned on an object attribute. > > > > > > > > On Feb 1, 2008 12:46 AM, Anstis, Michael (M.) <manstis1(a)ford.com&gt; > > > > wrote: > > > > > > > > > What about Agenda Groups? > > > > > > > > > > Rule "pick group X" > > > > > when > > > > > Fact( attribute = "condition1" ) > > > > > then > > > > > drools.setFocus("Group X") > > > > > end > > > > > > > > > > Rule "pick group Y" > > > > > when > > > > > Fact( attribute = "condition2" ) > > > > > then > > > > > drools.setFocus("Group Y") > > > > > end > > > > > > > > > > Rule "Group X1" > > > > > Agenda Group "Group X" > > > > > when > > > > > Smurf( ) > > > > > then > > > > > // Do something > > > > > end > > > > > > > > > > Rule "Group X2" > > > > > Agenda Group "Group X" > > > > > when > > > > > Smurfette( ) > > > > > then > > > > > // Something else > > > > > end > > > > > > > > > > etc > > > > > > > > > > ------------------------------ > > > > > *From:* rules-users-bounces(a)lists.jboss.org [mailto: > > > > > rules-users-bounces(a)lists.jboss.org] *On Behalf Of *Jai Vasanth > > > > > *Sent:* 31 January 2008 19:45 > > > > > *To:* rules-users(a)lists.jboss.org > > > > > *Subject:* [rules-users] Grouping rules > > > > > > > > > > Hi, > > > > > > > > > > > > > > > I am building a system where I would need to fire different > > > > > sets of rules based on some attribute in the fact object. > > > > > > > > > > Here are someways which I thought of, I was wondering if there > > > > > was something better than that. > > > > > > > > > > 1) I could do this by creating different sessions based on the > > > > > data attrbute (different sessions would have different rule packages based > > > > > on the attribute) > > > > > > > > > > or > > > > > > > > > > 2) Have all the rules fire (all the different sets of rules) > > > > > irrespective of the attribute and have them insert fact new objects into the > > > > > working memory. In the second round of rules, collect the (newly made) fact > > > > > objects based on the attribute and take that action. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Jai > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rules-users mailing list > > > > > rules-users(a)lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rules-users mailing list > > > > rules-users(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > _______________________________________________ > > rules-users mailing list > > rules-users(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > -- > Edson Tirelli > JBoss Drools Core Development > Office: +55 11 3529-6000 > Mobile: +55 11 9287-5646 > JBoss, a division of Red Hat @ www.jboss.com > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > > -- Edson Tirelli JBoss Drools Core Development Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of Red Hat @ www.jboss.com _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users