[rules-users] Chart notation, update, and infinite loops
Mark Proctor
mproctor at codehaus.org
Tue Nov 4 21:13:41 EST 2008
Greg Barton wrote:
> 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.
>
It's non-trivial, especially when evals are involved, but you are
welcome to have a go. Not even sure where to begin on this....
I imagine the first thing is that the PropagationContext will need a
binary mask, supplied by the modify keyword, which shows the fields
modified as part of the modify action. We will then need to do bitmap
masking to determine whether a propagation should continue down a route
or not. This may be an easier one to do on irc, if you can get there.
Just be aware that this is many days, if not weeks work, to get it right
with adequate unit testing.
Mark
> --- On Tue, 11/4/08, Edson Tirelli <tirelli at post.com> wrote:
>
>
>> From: Edson Tirelli <tirelli at post.com>
>> Subject: Re: [rules-users] Chart notation, update, and infinite loops
>> To: "Rules Users List" <rules-users at lists.jboss.org>
>> 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 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
>> _______________________________________________
>> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20081105/cd2f9b56/attachment.html
More information about the rules-users
mailing list