[rules-users] Unique events / facts in working memory

[Edson Tirelli]

   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 at 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 at gmail.com> wrote:
>
> > From: Justin King <justin.matthew.king at gmail.com>
> > Subject: [rules-users] Unique events / facts in working memory
> > To: "Rules Users List" <rules-users at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090819/ac7b5c5e/attachment.html