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@> 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@.jboss > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users@.jboss https://lists.jboss.org/mailman/listinfo/rules-users