[rules-users] Chart notation, update, and infinite loops
Edson Tirelli
tirelli at post.com
Tue Nov 4 20:06:29 EST 2008
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 at ge.com>
>
> 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 at ge.com> wrote:
> >
> >> From: Dan Seaver <dan.seaver at ge.com>
> >> Subject: Re: [rules-users] Chart notation, update, and infinite loops
> >> To: rules-users at 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 at ge.com> wrote:
> >> >
> >> >> From: Dan Seaver <dan.seaver at ge.com>
> >> >> Subject: [rules-users] Chart notation, update, and
> >> infinite loops
> >> >> To: rules-users at 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-tp20327483p20327483.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
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > rules-users mailing list
> >> > rules-users at 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-tp20327483p20329780.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
> >
> >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users at 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-tp20327483p20334594.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
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20081104/850a7c67/attachment.html
More information about the rules-users
mailing list