Re: [rules-users] drools quirks

On 18 September 2010 17:19, Matt Young <solid(a)youngdev.net <mailto:solid@youngdev.net>> wrote: ksession.execute(document); I suppose this inserts a single EventRulesDocument object. Here is the rule: package sample1 import sample1.bean.EventRulesDocument; import sample1.bean.Transaction; import java.util.Date; rule "Standard processing rule" when $doc : EventRulesDocument( ruleRun == false && # <<< Wolfgang event != null && event.eventType.eventCode == "testevent" ) then Transaction t = new Transaction(); t.setEvent($doc.getEvent()); t.setCategory($doc.getEvent().getEventType().getEventCode()); t.setTransactionAmount($doc.getEvent().getEventAmount()); t.setCreateTs(new Date()); t.setUsername($doc.getEvent().getCreateUsername()); modify( $doc ) {setRuleRun(true)}; # Wolfgang <<<<<< modify( $doc ) {addSaveTransaction(t)} ; Here it is: You modify the EventRulesDocument, which causes another activation of the same rule. One way of avoiding this is to add the rule attribute no-loop true; another one is what you've done. This isn't going to be your only rule?? This one alone is scant reason to use an RBS. fireAllRules( 1 ) isn't a good remedy, because (normally) a Production System relies on repeated firings, depending on rules and facts. end Additionally If any code in the world can be executed in the RHS, then why shouldn't I just use groovy as my rule language? At least then, I can write math like such: def num1=95; def num2=90; def num3=num2/num1; and all of the math is done with big decimal objects. IF there is no restriction on what can be done in the RHS what is the advantage to using a rules engine over a general purpose scripting language? There is a good section in the Drools Expert manual: "Why use a rule engine?". Don't do it just to be trendy ;-) The whole purpose for me choosing drools over Groovy eval() was that I didn't want to give my users the ability to spawn threads, allocate massive amounts of memory etc. Seriously now, a Domain Specifiy Language is the maximum corset you can force upon your users. But you'll have to know /all/ they /may /do, and all the conditions. -W On 09/18/2010 10:59 AM, Wolfgang Laun wrote: > On 18 September 2010 16:15, Matt Young <solid(a)youngdev.net <mailto:solid@youngdev.net> > <mailto:solid@youngdev.net <mailto:solid@youngdev.net>>> wrote: > > I just started using drools and this is my first time > implementing a rules engine. Everything has been pretty smooth > but I have some quirks that I am not sure I can live with. 1) for > some reason, > if I execute the Knowlege session against an object, the > knowlege session never returns. > > >> I don't understand the term "execute...against an object". Do >> you mean that you have just one fact inserted befor you call >> fireAllRules()? > >> But anyway, this call not returning is almost certainly due to >> a loop in your rules, or have you made sure that they don't? > > > The only way I can get the ksession to return is to make IF (obj == > null) part of the LHS and make > modify($input){setObj("complete")} part of the RHS This seems > like a deficiency since I have users writing their own rules, I > can see them forgetting this requirement. > > >> Writing rules is programming, no holds barred :-) > >> Look into Domain Specific Languages (DSL) as a cushion for the >> unwary. > > > > IS their a way to get the ksession to firerules only once? If > so what does that look like? > > >> kSession.fireUntilHalt( 1 ); > > > 2) It seems that any code I want can be executed in the RHS. I > could literally execute something like the following in the RHS. > > byte[] b= new byte[10000000000000]; // Really big memory waste > > I also could just start a bunch of threads. > > The point is that I am intending to let the users write their > own rules but I can't do that if there are no restrictions on > how/what can be done inside the rules. Any suggestions? Are > there sandboxes or filters I can activate to restrict the RHS? > > >> Again: DSL. > >> Also, Rule Templates might be the starting point; it'd depend >> on what the may be allowed to do. > >> And what about good old-fashioned training?! > >> -W > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> <mailto:rules-users@lists.jboss.org <mailto:rules-users@lists.jboss.org>> https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing > list rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-users - -- Cheers, Matt Young solid(a)youngdev.net <mailto:solid@youngdev.net> http://youngdev.net _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMlQ/QAAoJEO5jycTTPEzcTtsQAIPyaUtnu71jo5aCRy9xhmj2 E+zt3N/hc8tmKEFxFOhFdnD5ON2pRMXNNVtfqzfhP0l+5+luIpUtgzpKtCbo0Uby MwRvDU32GZ9ubg86+0N0jmqPM6rmYephbOwYoeY2uPaKGoNOy36HSbdtHkSrEcOS YSsl+P696tJZp/vS/ZX1hAn5yRJYQ+8GZz+bNzcHDufMIb3gMAwgzPFHp5VqQKnz LKbQEJEESZJbA/6ue0iLh5eZ7ctCzuvSPlvJN9zfTN0dIpvDqDZohl2lF/UIHVU3 lnpFx4s+s3ruJwQLGXEncdwDPLGEQX1or30XU9gjJiDUDMJFlgnkTSwRqpuWR0RW DCIzdC+piJbC6TKDn2PzOw+2H3OlJ07EXTqzYOIzuVFZYHrnHZ0dziYcAtTCry7H 4bhs+IRqhpDQwdcPz21wt/bxDmWcm4vUM63YvKYU/0Y0zXwXMlOeEQaic2TcRSO5 Ju3G3ZaNIn4k94+dyyGYbUn4CnA1iqXxV762moCgNWy2NJAM4Qyev+1dSfmSVBHE liLWS6bQJ9UitAb87QqfdkULAMOcrtrvzKGaYZBhxEQyMp7hUS28yGyeNv9tszC3 hIXU8oDl8y+F63HM1HUD0nO2+aVGJTXmB9/5ZLdyEQdtCBgMGndnYPIxQ9eaUgG9 +iSttUHr1fUENMjQqdQj =T8nI -----END PGP SIGNATURE-----