Heck, yeah, I'm up for it. Rulesfest is over, so I'm bored. :P

--- 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: greg_barton(a)yahoo.com, "Rules Users List" <rules-users(a)lists.jboss.org&gt; > Date: Tuesday, November 4, 2008, 7:54 PM > That is an excellent project, but it is deep in the core > engine. Great > opportunity to learn all about ReteOO and drools internals, > but will require > some research from your side... we know the general > solution, but you may > still find some obstacles that need to be removed as you > go. > > If you are willing to take the challenge, lets move the > discussion to > drools-dev and we can guide you. > > []s > Edson > > 2008/11/4 Greg Barton <greg_barton(a)yahoo.com&gt; > > >> 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 >> >> > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss, a division of Red Hat @ www.jboss.com > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev