[rules-users] Chart notation, update, and infinite loops
Greg Barton
greg_barton at yahoo.com
Tue Nov 4 20:42:54 EST 2008
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 <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
More information about the rules-users
mailing list