Re: [rules-users] In drools what is the exact difference between Insert and Update ??
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(a)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-...
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