[rules-dev] Re: [rules-users] Chart notation, update, and infinite loops
Greg Barton
greg_barton at yahoo.com
Tue Nov 4 22:53:26 EST 2008
Heck, yeah, I'm up for it. Rulesfest is over, so I'm bored. :P
--- 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: greg_barton at yahoo.com, "Rules Users List" <rules-users at lists.jboss.org>
> Date: Tuesday, November 4, 2008, 7:54 PM
> 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
More information about the rules-dev
mailing list