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