Re: [rules-users] Too many ACTIVATION "candidates"

>> I'd say that this rule should actually be written as 16 rules - one for >> each of the or'd together GoodsItems conditions, each of these rules would >> only depend on a single Fact and you won't get into this problem. > > True. This rule can be re-written as a series of 5 rules that do not > exhibit the explosion of activation candidates. I have done so and > everything worked fine. > >> >> Who controls the custom interface? If you can control then the simplest >> solution is to prevent them doing or's of conditions (though perhaps this >> may not fly with your customers). Alternatively have the interface output >> an intermediate form which you can then control the compilation of. > > The custom interface, you may think of it as a simplified Guvnor, is under > my total control as I've implemented it. > The problem is, that the user can use it to write these kinds of rules. > In theory, rule rewriting could be possible, but I'm not sure I can detect > these kinds of dependencies for any kind of rule that may be written. No, I think they should be rewritten as a series of 16 rules (one for each '||'. You could remove the option from the user of being able to 'or' together conditions and require each thing to be written as separate rules. This should reduce the Cartesian products for the majority of cases (although creative users could still possibly write statements like (fact1 != "thiswillneverhappen" && fact2 != "thiswillneverhappen2"...)/ > It there is a way that these kinds of cartesian product of activation > candidates can be estimated before hand (either by analyzing the rule or > by some other means), it would be great. > Any ideas are welcomed. It depends on how accurate you want it. Simplist option is to restrict the number of facts that a rule can match against (if they can only match against 3 facts the Cartesian product probably isn't too bad). Slightly more complicated you can assume the worst case scenario that every value of each fact type is included and multiple the count of each included fact together, if it exceeds a configured limit you decide that potentially the rule is too complicated. Getting much more complicated is to perform a much more accurate estimation of each fact based upon the constraints. You could either do this in code (perhaps a db query or some other way to apply the constraint). Another way to do this would be to decompose the rules so that you accumulate the result of each fact constraint first, check whether too many facts have been included and then use a from for each accumulation at the end (or something like that anyway). Thomas ************************************************************************************** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users