Just added a comment to my collective JIRA JBRULES-2785 for a bundle of documentation fixes.
Nathan, no need to create another JIRA. -W On 24 November 2010 16:02, Edson Tirelli <[email protected]> wrote: > 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 > _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
