[rules-users] Limiting rule evaluation--not firing

[Vincent Legendre]

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