Hi Nathan, Yes, can you please open a JIRA for us to improve the documentation on this aspect?
Sorry, sometimes I am bad at associating names to faces... :) Edson 2010/11/23 Nathan Bell <[email protected]>: > Edson, > > You are right to say that in our domain model Patient is a regular entity and > not an event. And, yes, I have read that blog post you referenced, and > actually discussed events with you in person briefly at the San Diego > conference this year. The only reason I declared patient as an event was > because I thought that the use of temporal operators required declaring the > object as an event. I've just skimmed the Fusion documentation again to see > if I missed where this was called out, but did not find it. Perhaps this > could be considered for a documentation enhancement? > > Thank You, > > Nathan Bell > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Edson Tirelli > Sent: Monday, November 22, 2010 7:55 PM > To: Rules Users List > Subject: Re: [rules-users] Temporal constraint not causing rule activation > when using StatefulKnowledgeSession.update() > > > I believe the documentation mentions this: events are supposed to > be immutable, except for data enrichment. Timestamp is cloned at the > moment an event is inserted into the session to prevent inconsistent > reasoning (you know, in case a creative user tries to modify the > timestamp field... ;) ). > > Besides that, Patient is an odd name for an event class, so either > there is a misunderstanding here, or you are using the wrong tool for > the job. If Patient is just a regular entity in your domain model, it > should not be declared as an event. Remember that you can use > point-in-time temporal operators (before, after, coincides) with any > Date/long attribute, no need to declare the class as an event class: > > Patient( birthdate after $someTimestamp ) > > If you do that, you will be able to modify patient instances and > rules will behave correctly. > > Try this: > > http://blog.athico.com/2010/07/events-to-be-or-not-to-be-that-is.html > > Edson > > > > 2010/11/22 Nathan Bell <[email protected]>: >> To demonstrate the issue I have simplified the following sample rule to just >> the components needed to demonstrate the issue. The example rule I'm posting >> here uses the "after" operator; I have also tried this same test with the >> before operator. In this sample the rule named "AfterRule" will activate if >> the facts are initially inserted in a state matching the pattern. However, >> if the facts are inserted in a state that does not match, and then later >> updated to match the pattern using StatefulKnowledgeSession.update() the >> rule will not activate. >> >> >> >> Consider the following DRL: >> >> >> >> package test.rules; >> >> >> >> dialect "java" >> >> >> >> import java.util.Date; >> >> import com.p1s.mps.model.RuleTime; >> >> import com.p1s.mps.model.Patient; >> >> >> >> declare RuleTime >> >> @role( event ) >> >> @timestamp( time ) >> >> end >> >> >> >> declare Patient >> >> @role( event ) >> >> @timestamp( birthDate ) >> >> end >> >> >> >> rule "AfterRule" >> >> when >> >> $now : RuleTime( ) >> >> Patient( this after $now ) >> >> then >> >> System.out.println("after"); >> >> end >> >> >> >> >> >> Separately in a unit test the following actions are performed: >> >> 1. Insert an instance of RuleTime into the session where time is set >> to now. >> >> 2. Insert an instance of a patient into the session where the >> birthdate is set to (now - 1 day). [This makes the birthdate in the past so >> the rule does not activate] >> >> 3. Call fireAllRules(). The rule does not activate, as expected. >> >> 4. Modify the patient instance to have a birthdate set to (now + 1 >> day). >> >> 5. Invoke update() on knowledge session. >> >> 6. Call fireAllRules(). The rules does not activate. It should >> activate here. >> >> >> >> >> >> If I change step 5 to a retract + insert then the rule will activate in step >> 6 as expected. >> >> >> >> >> >> Thank You, >> >> Nathan Bell >> >> _______________________________________________ >> rules-users mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss by Red Hat @ www.jboss.com > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
