Thats ok, because if you dont call your function, you dont know if that rule should be fired or not. But I am concerning about agenda-group, where I know exactly one or more groups or rules will not be fired but they are still being evaluated. I ended up moving all the matching/checking to the "then" part for all my rules to speed things up. Now my "when" part is super clear -- View this message in context: http://drools.46999.n3.nabble.com/Agenda-group-in-fact-insert-time-tp4023... Sent from the Drools: User forum mailing list archive at Nabble.com.

Thank you so much Wolfgang (is that your name? I saw that in some other posts. Cool )! Yes, now I know the benefit of this approach, now I am wondering why we are only left with one option? Could I propose a new and easy API that you can create a session from kbase with rules in a particular agenda-group(s)? Then start inserting fact to that session, so that rules in other agenda-groups will not be evaluated under this user's choice. Until then, do you think maintaining different kbases for each agenda-group (i.e. one agenda-group in one kbase) is a good idea? When rules in an agenda-group are needed to be fired, that kbase is used to create session(s). When rules across more than one agenda-groups are needed to be fired, those kbases can be added together to form a bigger kbase to create a session. This method is not perfect nor an ultimate solution. This is just a trade off for performance vs flexibility. By doing that, we for sure cannot write dynamic agenda-group focusing rules (those rules will not break down, just there will be no such group for that session) and which groups to fire must be planned beforehand. -- View this message in context: http://drools.46999.n3.nabble.com/Agenda-group-in-fact-insert-time-tp4023... Sent from the Drools: User forum mailing list archive at Nabble.com.

Thank you Wolfgang for your detailed reply. So maintaining rules in separate compiled resources is more preferable than using a single kbase to spawn separate sessions. I really want to try this idea. Looks promising. When can we have this "extends" feature? -- View this message in context: http://drools.46999.n3.nabble.com/Agenda-group-in-fact-insert-time-tp4023... Sent from the Drools: User forum mailing list archive at Nabble.com.

After a few testing, it seems that this "rule extends rule" feature is not exactly what I want. Say rule "B" extends "A" rule "A" will be evaluated. This is OK. when it comes to rule "B", first, conditions in rule "A" will be evaluated again, then the conditions in rule "B" will be evaluated. That is not what I expected in this feature. May be it is only half baked? I would love to see this feature to be enchanted. Like if rule "B" extends "A", rule "C" extends "A" then once rule "A" is evaluated, the result (to be executed or not) should be used when evaluating rule "B" and rule "C". If rule "A" does not match the conditions, none of rule "B" nor rule "C" should be evaluated again. If rule "A" matches the conditions, when it comes to rule "B" or rule "C", those conditions in rule "A" should not be evaluated again. Otherwise it is just like I repeated the conditions of rule "A" in rule "B" and rule "C" again. The only saving from this feature is in the code by typing less. -- View this message in context: http://drools.46999.n3.nabble.com/Agenda-group-in-fact-insert-time-tp4023... Sent from the Drools: User forum mailing list archive at Nabble.com.

On 11 May 2013, at 16:23, Sonata <plz.write.to(a)gmail.com&gt; wrote: "extends" implicitly takes advantage of node sharing. If B extends A, when you evaluate B you effectively get A for free. It will not need to re-evaluate any conditions specific to A, as they re already done. Mark

Ah, ok, thank you Wolfgang and Mark. So I will stick to the Focus blocker or contexts semaphores to short circuit my rules in different groups for the time being and wait for Mark's new lazy algorithm. Good work Droolers! -- View this message in context: http://drools.46999.n3.nabble.com/Agenda-group-in-fact-insert-time-tp4023... Sent from the Drools: User forum mailing list archive at Nabble.com.