Greg is right if you want to keep it just using expert features. Now if you model your Singleton as an event, you could use the timestamp instead of create a specific attribute for that:
oldSingleton : Singleton( $id : id ) newSingleton : Singleton( id == $id, this after oldSingleton ) Or, if you have just a few rules that use your Singleton and you activate the STREAM mode, you could simply use a sliding window: rule "my rule that uses the singleton" when $singleton : Singleton( ... ) over window:length(1) // more patterns... then // do something end []s Edson 2009/8/18 Greg Barton <greg_bar...@yahoo.com> > You need some comparable property in the singleton object that's > monotonically increasing. Then you can have a rule like the following that > must be of higher salience than the rules you want to protect from duplicate > singletons. i.e.: > > rule "EnforceOneSingleton" > when > oldSingleton : Singleton( $id : id, $version : version ) > newSingleton : Singleton( id == $id, version > $version) > then > System.out.println( "Retracting old Singleton " + > oldSingleton.getId() + " version " + oldSingleton.getVersion()); > retract( oldSingleton ); > end > > --- On Mon, 8/17/09, Justin King <justin.matthew.k...@gmail.com> wrote: > > > From: Justin King <justin.matthew.k...@gmail.com> > > Subject: [rules-users] Unique events / facts in working memory > > To: "Rules Users List" <rules-users@lists.jboss.org> > > Date: Monday, August 17, 2009, 6:20 PM > > I'm building an application that will > > over time record changes in a certain component (not at any > > set interval, could occur any time). The component can > > possibly be uniquely identified via some kind of id. Is > > there a way that when I insert an event / fact recording a > > change of state in this component I can remove the previous > > one, so as there is only ever one fact / event recording the > > current state of the component. If the previous one existed > > it may cause rules to fire which should not. > > > > > > Cheers, > > > > Justin > > > > > > -----Inline Attachment Follows----- > > > > _______________________________________________ > > rules-users mailing list > > rules-users@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > 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 rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users