[rules-users] Chart notation, update, and infinite loops
Edson Tirelli
tirelli at post.com
Tue Nov 4 20:54:33 EST 2008
That is an excellent project, but it is deep in the core engine. Great
opportunity to learn all about ReteOO and drools internals, but will require
some research from your side... we know the general solution, but you may
still find some obstacles that need to be removed as you go.
If you are willing to take the challenge, lets move the discussion to
drools-dev and we can guide you.
[]s
Edson
2008/11/4 Greg Barton <greg_barton at yahoo.com>
> 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
>
>
>
> _______________________________________________
> 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/beed439b/attachment.html
More information about the rules-users
mailing list