Heck, yeah, I'm up for it. Rulesfest is over, so I'm bored. :P --- On Tue, 11/4/08, Edson Tirelli <[EMAIL PROTECTED]> wrote:
> From: Edson Tirelli <[EMAIL PROTECTED]> > Subject: Re: [rules-users] Chart notation, update, and infinite loops > To: [EMAIL PROTECTED], "Rules Users List" <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > > > 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 > <[EMAIL PROTECTED]> wrote: > > > > > From: Edson Tirelli <[EMAIL PROTECTED]> > > > Subject: Re: [rules-users] Chart notation, > update, and infinite loops > > > To: "Rules Users List" > <[EMAIL PROTECTED]> > > > 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 <[EMAIL PROTECTED]> > > > > > > > > > > > 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 > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > >> From: Dan Seaver > <[EMAIL PROTECTED]> > > > > >> Subject: Re: [rules-users] Chart > notation, > > > update, and infinite loops > > > > >> To: [EMAIL PROTECTED] > > > > >> 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 > > > > >> <[EMAIL PROTECTED]> wrote: > > > > >> > > > > > >> >> From: Dan Seaver > > > <[EMAIL PROTECTED]> > > > > >> >> Subject: [rules-users] > Chart > > > notation, update, and > > > > >> infinite loops > > > > >> >> To: > [EMAIL PROTECTED] > > > > >> >> 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-tp20327483p20327483.html > > > > >> >> Sent from the drools - > user mailing > > > list archive > > > > >> at > > > > >> >> Nabble.com. > > > > >> >> > > > > >> >> > > > _______________________________________________ > > > > >> >> rules-users mailing list > > > > >> >> > [EMAIL PROTECTED] > > > > >> >> > > > > >> > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > _______________________________________________ > > > > >> > rules-users mailing list > > > > >> > [EMAIL PROTECTED] > > > > >> > > > > > 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-tp20327483p20329780.html > > > > >> Sent from the drools - user mailing > list > > > archive at > > > > >> Nabble.com. > > > > >> > > > > >> > > > _______________________________________________ > > > > >> rules-users mailing list > > > > >> [EMAIL PROTECTED] > > > > >> > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rules-users mailing list > > > > > [EMAIL PROTECTED] > > > > > > > > > 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-tp20327483p20334594.html > > > > Sent from the drools - user mailing list > archive at > > > Nabble.com. > > > > > > > > > _______________________________________________ > > > > rules-users mailing list > > > > [EMAIL PROTECTED] > > > > > 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 > > > [EMAIL PROTECTED] > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > _______________________________________________ > > rules-users mailing list > > [EMAIL PROTECTED] > > 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 [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
