[rules-users] Limiting rule evaluation--not firing
Vincent Legendre
vincent.legendre at eurodecision.com
Mon Mar 21 09:47:03 EDT 2011
ok.
So the only way to do that is to add a control fact, and update it at
runtime...
Do you think that using the "control fact" method will speed up the
execution time for a large ruleset that have different ruleflow-group ?
My feeling is yes, especially if "first" rules does many updates, but I
haven't done any tests.
Le 21/03/2011 14:37, Swindells, Thomas a écrit :
>
> The thing to remember is that fact evaluation occurs at object
> insert/update time, not at the point you call fireAllRules. Salience,
> Agenda and rufeflow control on the other hand are runtime conditions
> which control which rules are actually activated in what order.
>
> Thomas
>
> *From:*rules-users-bounces at lists.jboss.org
> [mailto:rules-users-bounces at lists.jboss.org] *On Behalf Of *Vincent
> Legendre
> *Sent:* 21 March 2011 13:34
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Limiting rule evaluation--not firing
>
> And what about ruleflow-group ?
> There is no network filtering for that too ? The ruleflow-group
> behaves like an agenda filter, but still evaluate all nodes ?
> Could we imagine setting "tags" to nodes, and stop propagation for
> node that does not declare the current task tag ?
>
>
> Le 21/03/2011 14:20, Edson Tirelli a écrit :
>
> The algorithm as is does eager evaluation, as for the general case
> that is still better than doing selective evaluation.
>
> If, in your case, the decision of which rules to fire is an
> arbitrary application decision, and not based on the actual
> constraints of the rules themselves, then the only way would be by
> creating a control fact:
>
> rule 1
>
> when
>
> ControlFact( phase == Phase.ONE )
>
> ...
>
> rule 2
>
> when
>
> ControlFact( phase == Phase.TWO )
>
> ...
>
> This way, if the control fact is the first pattern in each rule it
> effectively disables all the beta evaluations for rules of phases
> other than the current one. Just be aware that by blocking the eager
> evaluation this way, phase switches are heavier than without the
> control fact, where most constraints were already previously
> evaluated. Obvious, but worth saying out loud... :)
>
> There is also a feature that Leonardo is working on that makes the
> engine automatically unlink and relink parts of the network, based on
> the existence and possibility of matching the other required facts in
> a rule LHS. It might achieve similar results to what you are looking
> for in some cases, but that is totally based on the constraints in
> there and not on any arbitrary application decision.
>
> Edson
>
>
> ------------------------------------------------------------------------
>
> **************************************************************************************
> This message is confidential and intended only for the addressee. If
> you have received this message in error, please immediately notify the
> postmaster at nds.com and delete it from your system as well as any
> copies. The content of e-mails as well as traffic data may be
> monitored by NDS for employment and security purposes. To protect the
> environment please do not print this e-mail unless necessary.
>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex,
> TW18 4EX, United Kingdom. A company registered in England and Wales.
> Registered no. 3080780. VAT no. GB 603 8808 40-00
> **************************************************************************************
>
>
> _______________________________________________
> 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/20110321/a14b060b/attachment.html
More information about the rules-users
mailing list