There may be very good reasons to have Patient with @role(event). But for testing rules with temporal operators I find it much easier to use a pseudo-clock for telling the Session about "now".
Also, a rule with a timer, inserting events with a very short expiry time provides a very good way of producing ticks, discrete moments in time, with which it is easy to reason. -W On 23 November 2010 04:54, Edson Tirelli <[email protected]> wrote: > 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
