�� 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_barton@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.king@gmail.com> wrote:

> From: Justin King <justin.matthew.king@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