Your rule doesn't make sense to me. It accumulates three Sets for
cardinality tests from the same domain ($loan.garantees) by filtering these
objects by the constraints:
Set-1: typegarantee.code == "H"
Set-2: typegarantee.code == "H" || typegarantee.code == "O"
Set-3: typegarantee.code == "H"
Clearly Set-1 and Set-3 will have the same cardinality - so why compute and
test it twice?
Obviously, the second set will only have cardinality one if there are no
"garantee" facts with typegarantee.code == "O", and so this is a weird
way
of asserting that.
Cardinality tests are better written using the accumulate function "count".
There is no point in writing
$loan : loan() from $loanEvaluated.loan
if $loanEvaluated.loan is not a Collection. Simply use:
$loanEvaluated : loanEvaluated(..., $loan : loan )
The frequent use of "from $loan.garantees" insinuates that the
"garantee"
objects contained in the loan.garantee Collection should be inserted as
facts, preferably with a link field to the "loan" fact they belong to. This
would make evaluation much more efficient, and there wouldn't be much of
repeated evaluation going on after some other rule updates loanEvaluated.
However, a general solution of the multiple update might still be advisable.
This can be done by
- saving all computed update values (such as "initial value") in an
object S separate from loanEvaluated (possibly but not necessarily of the
same type),
- *not *updating this temporary safekeeping object S,
- using a low salience rule to transfer whatever is in S to the
pertaining loanEvaluated. (Alternatively, you might employ agenda groups for
the simple flow between main and computation.)
-W
PS: You might adhere to the Java naming conventions using upper case
initials for type names.
PPS: The correct spelling is "g*u*arantee".
On 25 May 2011 01:55, dbfree75 <wbismuth(a)yahoo.fr> wrote:
I'm still using such solution .
Here an example of rule where I nees to set the
originalPropertyValuationLoan :
rule "OriginalPropertyValuationLoan - NbSecuredGaranteeUnderLoan >= 1 -
garantee H - postCode equivalent - initialValue equivalent"
no-loop
salience 970
dialect "mvel"
when
$controlFact : ControlFact(phase == "INITIAL")
$loanEvaluated : loanEvaluated(nbSecuredGaranteeUnderLoan
>= 1,
originalPropertyValuationLoan == null)
$loan : loan() from $loanEvaluated.loan
$garantee : garantee(typegarantee.code == "H" , initialValue
!= null) from
$loan.garantees
$postCodes : Set(size == 1)
from accumulate(
garantee(typegarantee.code == "H", $n :
postCodeInGarantee) from $loan.garantees,
collectSet($n)
)
$garantees : Set(size == 1)
from accumulate(
garantee(typegarantee.code == "H" ||
typegarantee.code == "O", $n : typegarantee.code) from $loan.garantees,
collectSet($n)
)
$initialValue : Set(size == 1)
from accumulate(
garantee(typegarantee.code == "H", $n : initialValue ) from
$loan.garantees,
collectSet($n)
)
then
$loanEvaluated.originalPropertyValuationLoan =
$garantee.initialValue
update($loanEvaluated)
#System.out.println("OriginalPropertyValuationLoan -
NbSecuredGaranteeUnderLoan > 1 : " +
$loan.loanEvaluated.originalPropertyValuationLoan);
end
In case this rule isn't fired because any of these conditions isn't set, on
update after any other property has been set this rule will be fired again
--
View this message in context:
http://drools.46999.n3.nabble.com/Update-function-usage-for-java-objects-...
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