[rules-users] Chart notation, update, and infinite loops
Dan Seaver
dan.seaver at ge.com
Tue Nov 4 19:56:17 EST 2008
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.
More information about the rules-users
mailing list