[rules-users] Update function usage for java objects to be retrieved for database update

Wolfgang Laun wolfgang.laun at gmail.com
Wed May 25 02:18:12 EDT 2011


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 at 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-to-be-retrieved-for-database-update-tp2981879p2982338.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110525/40b41aba/attachment.html 


More information about the rules-users mailing list