[rules-dev] Re: [rules-users] Chart notation, update, and infinite loops
Edson Tirelli
tirelli at post.com
Wed Nov 5 11:30:26 EST 2008
:) Excellent!! That's the spirit!
For the java grammar, I can get you started. For MVEL talk to Mike.
[]s
Edson
2008/11/5 Mark Proctor <mproctor at codehaus.org>
> Greg Barton wrote:
>
> Heck, yeah, I'm up for it. Rulesfest is over, so I'm bored. :P
>
>
> heh, ok :)
>
> I'd start with the creation of a compile time bitmap mask of the field
> changed. To do this you'll need to make it work for both the java and the
> mvel dialect. For the java dialect you'll have to hook into the antlr
> grammar and identify setters - nested setters we can ignore for now - and a
> bitmap mask can be made from that. On the MVEL dialect I'm not sure, you'll
> need to speak to the MVEL author (see Mike Brock in CC) on how to get that
> information.
>
> While you are there, you may want to capture the assert, retract info as
> this can then be used by the verification guys for subsumption - I know this
> was a blocker for them.
>
> Mark
>
> --- On Tue, 11/4/08, Edson Tirelli <tirelli at post.com> <tirelli at post.com> wrote:
>
>
>
> From: Edson Tirelli <tirelli at post.com> <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> <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> <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> <tirelli at post.com> wrote:
>
>
> From: Edson Tirelli <tirelli at post.com> <tirelli at post.com>
> Subject: Re: [rules-users] Chart notation,
>
>
> update, and infinite loops
>
>
> To: "Rules Users List"
>
>
> <rules-users at lists.jboss.org> <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> <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> <dan.seaver at ge.com> wrote:
>
>
> From: Dan Seaver
>
>
> <dan.seaver at ge.com> <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> <dan.seaver at ge.com> wrote:
>
>
> From: Dan Seaver
>
>
> <dan.seaver at ge.com> <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 listrules-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 listrules-users at lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
>
>
> rules-users mailing listrules-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 listrules-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 listrules-users at lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> JBoss, a division of Red Hat @ www.jboss.com
>
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
--
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-dev/attachments/20081105/e0e5bf94/attachment.html
More information about the rules-dev
mailing list