This uses several terms I'm not familiar with in this context, but it seems that
1. a ule uniquely determines a Class to be instantiated on its RHS 2. a set of parameters is required that, in turn, depends on the Class determined according to (1). I do not understand why these parameters cannot be inserted as facts. Each parameter set (!) would be a fact with one field containing the Class, and this could be matched in the rule, passing parameters to the processing to be done in the same rule. $p: Params( clazz == (FactorType1.class), $pSet: paramSet ) -W On 27 September 2011 15:11, JohnnyCaimbridge <nbo...@nycm.com> wrote: > NOTE: Reposted because I only just subscribed to the mailing list. > > Hello, > > I have a set of Fact types which represent factors matched and used > throughout the other rules. Each of these Fact types may be derived in a > variety of mutually exclusive ways--ie based on the line of business or > other factors. The rules are all well-defined for these Facts. Something > like this: > > declare FactorType1 > value : BigDecimal > end > > rule "FactorType1" > when > LineOfBusiness( this == LineOfBusiness.LOB1 ) > // some other conditions > $prms : Params() // ***provisional*** where to specify needed context > dependent parameters? see below > then > BigDecimal value = new BigDecimal("0"); > // ... determine value based on conditions and $prms > insert( new FactorType1(value) ); > end > > // <some other mutually exclusive rules to derive FactorType1 here> > > The problem is that in the rules which match these Facts, there are many > context dependent (ie *always* unique to that particular rule) parameters > which must be "passed" to the derivation of those Facts. I'm referring to > these as "Params" above. Now, a rule that uses FactorType1: > > rule "a rule that uses FactorType1" > when > // some conditions > FactorType1( $value ) > $prms : Params(prm1,prm2,prm3,...) // ***provisional*** how to indicate > that FactorType1 should use these parameters in its derivation? > then > // perform some calculation with $value > end > > The parameters which these Facts use cannot be asserted as Facts > themselves. > They are unique to the rules which match on the FactorTypes, so that would > mean I'd need a duplicate rule for every rule that uses a FactorType (even > with "rule inheritance", this is excessive). > > It's almost as if I need to specify a "partial derivation" or "partial > unification" of the Fact type, which is only asserted once a rule indicates > that it is providing the "unbound" portion of the derivation. I understand > queries can be used for some sort of partial unification, but I have no > clue > how to apply them to my problem and I can't find any good examples or > documentation on their usage/behavior. > > Thanks in advance > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/Partial-Unification-Derivation-of-Facts-tp3372546p3372546.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users >
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users