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 <nbower(a)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...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users