[rules-users] In drools what is the exact difference between Insert and Update ??

Wolfgang Laun wolfgang.laun at gmail.com
Thu Mar 29 03:03:20 EDT 2012


Hi Bhushan,

some amendments to Davide's comments.

Salience: You might argue for one (1) rule (per class) with low
salience to detect a fact (of that class) that failed to be processed
(similar to the "default" in a switch).

Globals: In LHS *only* for introducing *constant* data, to compare to
fact data. In RHS code where the global is an object providing a
service, e.g., to send a matched fact to some external processor,
store it in a DB or whatever.

RHS all in Drools: Using Java static methods for certain tasks has the
benefit that they are easier to unit test.

UPDATE: You must use update (or, preferably, modify) if, and only if,
you have to change your facts AND changed facts must be processed by
other rules. - There is a scenario where you might invoke setters on a
fact object but you do not intend that the modified field is ever
processed by a rule: then do not call update/modify.

However, you might also design your system in a way where you do not
update/modify primary facts. Instead, to keep track of truths
discovered by
your rules, you insert new (secondary) facts of types according to
your design, linking them to your primary fact.

rule discover
when
    $p: Primary( color == Color.GREEN, shape == Shape.ROUND )
then
   insert( new RoundAndGreen( $p ) )
end

rule process
when
     $p: Primary()
     $rag: RoundAndGreen( primary == $p )
then
    process(...)...
    retract(...),...
end

HTH
-W

On 28/03/2012, Davide Sottara <dsotty at gmail.com> wrote:
> Dear Bhushan, the recommendations you got from your architect should be
> intended as best practices, not as strict instructions. Indeed, it depends
> on what kind of rules you are writing and their business logic.
>
> I agree that functions and globals should not be abused, and that salience
> and groups should be intended as execution constraints, not as fine-grained
> flow control, but I would reason on a case-by-case basis.
>
> Now, as far as "update" is concerned... update is NEEDED to let the engine
> know that some fact has changed. The only way not to use update is NOT TO
> LET FACTS CHANGE. This is hardly possible in dynamic systems.
> In that case, the only alternative is to replicate and insert the facts with
> different state identifiers (e.g. timestamps): Person( name=david, age=25 ),
> Person( name=david, age=26 ), Person( name=david, age=27 ).....
> This is indeed a purely declarative approach, which you pay with additional
> logic - to select only the "current" facts - and additional memory
> consumption.
> If the reason for not using update is that rules fire when they shouldn't,
> then I agree that no-loop is not the best choice. It works only for the same
> rule where you do the update, so it's hardly a safe way to proceed.
> I would suggest, instead, to add constraints preventing the modified version
> of the fact to trigger rules which have already fired. If you could provide
> an example with one of your use cases, it would be easier to discuss the
> pros and cons
> Best
> Davide
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/In-drools-what-is-the-exact-difference-between-Insert-and-Update-tp3865471p3866107.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
>



More information about the rules-users mailing list