Re: [rules-users] Chart notation, update, and infinite loops

I thought drools had this. If you point me in the right direction (and you have the time) I'd be happy to work on that.

--- On Tue, 11/4/08, Edson Tirelli <tirelli(a)post.com&gt; wrote: > From: Edson Tirelli <tirelli(a)post.com&gt; > Subject: Re: [rules-users] Chart notation, update, and infinite loops > To: "Rules Users List" <rules-users(a)lists.jboss.org&gt; > Date: Tuesday, November 4, 2008, 7:06 PM > Dan, > > This is a feature that is in our to-do list. Jess calls > it "slot specific > updates". We did not had the time yet to implement it > though. :( > > []s > Edson > > 2008/11/4 Dan Seaver <dan.seaver(a)ge.com&gt; > > >> Your understanding is very close to what I'm >> > looking for. I don't mind > >> having >> multiple rule activations in other areas of the >> > ruleset when the Fact is > >> updated, I just don't want the current rule, the >> > one with the update > >> statement, to be reactivated. >> >> Accumulate plus no-loop works fine for the specific >> > case of updating > >> amounts, but I'd like to have something generic >> > for more sophisticated > >> logic >> that would be implemented in the "then" >> > clause. > >> Maybe if there was something that looked specifically >> > at each property of > >> the update? In this case, the "when" clause >> > is looking at the "name" > >> property and the "then" clause is updating >> > the "amount" property. As the > >> "name" is not being changed, then the update >> > wouldn't reactivate the rule. > >> >> Greg Barton wrote: >> >>> If you have the control fact that handles the >>> > "applied == false" > >> condition >> >>> you wouldn't need to prevent reactivation of >>> > the rule. It would be > >>> handled by the condition. >>> >>> I'm thinking Edson's accumulate >>> > suggestion would be best, at this point. > >>> If I understand correctly, what you want is this: >>> >>> 1) One rule Fact/Charge activation per Charge >>> > instance, with no > >>> reactivation when the Fact is updated. >>> 2) Other Fact dependent rule activations when the >>> > Fact is updated. > >>> The problem with making (1) happen is that >>> > you'd still have the matched > >>> Fact being updated once per Charge, which could >>> > lead to reactivation of > >>> the rules in (2) multiple times, which you may >>> > not want. If you use > >>> accumulate in the Fact/Charge rule, plus no-loop >>> > to prevent reactivation, > >>> you get the best of both worlds: single >>> > activation of the Fact/Charge > >>> rule, with a single update to notify other rules >>> > that the Fact has > >>> changed. >>> >>> I think what you're after is some kind of >>> > "modify group," where multiple > >>> calls to modify are counted as just one, and >>> > rules are notified when the > >>> group is closed out. I'm not sure how that >>> > would be implemented, because > >>> how do you know when the modifications are >>> > finished? A low priority > >> rule, >> >>> possibly? Anyway, it doesn't exist in >>> > drools, afaik. > >>> You could do that kind of thing with an >>> > additional rule that tests for > >> the >> >>> nonexistence of an unprocessed Charge, then does >>> > the update. Adding in > >>> the control fact for tracking Charges: >>> >>> rule "Update Amount" >>> when >>> amountFact : Fact(name == >>> > "Amount") > >>> $charge : Charge() >>> chargeTracker : ChargeTracker(charge == >>> > $charge, applied == false) > >>> then >>> Double amount = amountFact.getAmount(); >>> Double chargeAmount = charge.getAmount(); >>> amountFact.setAmount(amount + >>> > chargeAmount); > >>> chargeTracker.setApplied(true); >>> update(charge); >>> end >>> >>> rule "Close Facts After Charges >>> > Applied" > >>> no-loop false >>> when >>> amountFact : Fact(name == >>> > "Amount") > >>> not ChargeTracker(applied == false) >>> then >>> update(amountFact); >>> end >>> >>> You'd probablt also have to prevent the >>> > "Close Facts" rule from firing > >>> when there's just no ChargeTrackers in >>> > working memory, too. > >>> Give that a try. >>> >>> --- On Tue, 11/4/08, Dan Seaver >>> > <dan.seaver(a)ge.com&gt; wrote: > >>>> From: Dan Seaver <dan.seaver(a)ge.com&gt; >>>> Subject: Re: [rules-users] Chart notation, >>>> > update, and infinite loops > >>>> To: rules-users(a)lists.jboss.org >>>> Date: Tuesday, November 4, 2008, 1:55 PM >>>> Greg, >>>> 1) Yes, in this case I'm looking for the >>>> > cartesian > >>>> join. >>>> 2) No, I can't add a property to Charge >>>> > as it's > >>>> part of our corp Object >>>> Model. >>>> >>>> However, I could create a third object that >>>> > manages whether > >>>> the Charge has >>>> been processed which works just fine. Unless >>>> > there is a > >>>> simpler strategy / >>>> technique, I'll go with that. >>>> >>>> Do you know of any way to keep the rule from >>>> > being put back > >>>> on the agenda >>>> when amountFact is updated? I want other >>>> > rules to know that > >>>> it's been >>>> updated, just not the rule that made the >>>> > change. > >>>> Dan >>>> >>>> >>>> Greg Barton wrote: >>>> >>>>> 1) Do you want to apply all Charges in >>>>> > working memory > >>>> to all "Amount" >>>> >>>>> Facts? I ask because the rule is a >>>>> > cartesian join > >>>> (i.e. no relation >>>> >>>>> between matched objects) and that >>>>> > sometimes performs > >>>> in ways users don't >>>> >>>>> expect. (i.e. all combinations of >>>>> > objects that match > >>>> the conditions are >>>> >>>>> affected by the rule) >>>>> 2) Can you add a property to the Charge >>>>> > object? Then > >>>> you could use a >>>> >>>>> boolean named "applied" to >>>>> > prevent future > >>>> matches. >>>> >>>>> Rule "Update Amount" >>>>> when >>>>> amountFact : Fact(name == >>>>> > "Amount") > >>>>> charge : Charge(applied == false) >>>>> then >>>>> Double amount = >>>>> > amountFact.getAmount(); > >>>>> Double chargeAmount = >>>>> > charge.getAmount(); > >>>>> amountFact.setAmount(amount + >>>>> > chargeAmount); > >>>>> update(amountFact); >>>>> charge.setApplied(true); >>>>> update(charge); >>>>> end >>>>> >>>>> If a charge could be applied to multiple >>>>> > Facts you > >>>> could maintain an >>>> >>>>> "appliedTo" list of Facts in >>>>> > the Charge, and > >>>> check that instead of a >>>> >>>>> simple boolean. >>>>> >>>>> --- On Tue, 11/4/08, Dan Seaver >>>>> >>>> <dan.seaver(a)ge.com&gt; wrote: >>>> >>>>>> From: Dan Seaver >>>>>> > <dan.seaver(a)ge.com&gt; > >>>>>> Subject: [rules-users] Chart >>>>>> > notation, update, and > >>>> infinite loops >>>> >>>>>> To: rules-users(a)lists.jboss.org >>>>>> Date: Tuesday, November 4, 2008, >>>>>> > 11:50 AM > >>>>>> I'm trying to find a good >>>>>> > technique for > >>>> updating >>>> >>>>>> specific facts in working >>>>>> memory. What I'm currently doing >>>>>> > is something > >>>> like >>>> >>>>>> this: >>>>>> >>>>>> Rule "Update Amount" >>>>>> when >>>>>> amountFact : Fact(name == >>>>>> >>>> "Amount") >>>> >>>>>> charge : Charge() >>>>>> then >>>>>> Double amount = >>>>>> > amountFact.getAmount(); > >>>>>> Double chargeAmount = >>>>>> > charge.getAmount(); > >>>>>> amountFact.setAmount(amount + >>>>>> > chargeAmount); > >>>>>> update(amountFact); >>>>>> end >>>>>> >>>>>> The update statement causes an >>>>>> > infinite loop. > >>>>>> I tried using no-loop, which works >>>>>> > if there is 1 > >>>> charge, >>>> >>>>>> but not if there >>>>>> are more than one. >>>>>> >>>>>> Any help with solutions or >>>>>> > strategies would be > >>>> much >>>> >>>>>> appreciated. >>>>>> -- >>>>>> View this message in context: >>>>>> >>>>>> > http://www.nabble.com/Chart-notation%2C-update%2C-and-infinite-loops-tp20... > >>>>>> Sent from the drools - user mailing >>>>>> > list archive > >>>> at >>>> >>>>>> Nabble.com. >>>>>> >>>>>> >>>>>> > _______________________________________________ > >>>>>> 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 > >>>>> >>>> -- >>>> View this message in context: >>>> >>>> > http://www.nabble.com/Chart-notation%2C-update%2C-and-infinite-loops-tp20... > >>>> Sent from the drools - user mailing list >>>> > archive at > >>>> Nabble.com. >>>> >>>> >>>> > _______________________________________________ > >>>> 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 > >>> >> -- >> View this message in context: >> >> > http://www.nabble.com/Chart-notation%2C-update%2C-and-infinite-loops-tp20... > >> Sent from the drools - user mailing list archive at >> > Nabble.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 > 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 > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users