Problem with eval and RC2

[Paul Smith-3]

Hi Guys,

I've just put RC2 in place but now rules that did work with RC1 don't build
any more. An example is as follows:

package testing

import testing.TestParam

rule "testEval"

    when
        TestParam(s : value -> eval(s != null))
    then
        System.out.println("Do something");
end

When I do the addPackage I get the following:

org.drools.rule.InvalidRulePackage: unknown:8:25 mismatched token:
[@32,116:119='eval',<56>,8:25]; expecting type '('

    at org.drools.rule.Package.checkValidity(Package.java:378)
    at org.drools.reteoo.RuleBaseImpl.addPackage(RuleBaseImpl.java:303)
    at testing.EvalTest.testFunction(EvalTest.java:23)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at junit.framework.TestCase.runTest(TestCase.java:154)
    at junit.framework.TestCase.runBare(TestCase.java:127)
    at junit.framework.TestResult$1.protect(TestResult.java:106)
    at junit.framework.TestResult.runProtected(TestResult.java:124)
    at junit.framework.TestResult.run(TestResult.java:109)
    at junit.framework.TestCase.run(TestCase.java:118)
    at junit.framework.TestSuite.runTest(TestSuite.java:208)
    at junit.framework.TestSuite.run(TestSuite.java:203)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
RemoteTestRunner.java:478)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
RemoteTestRunner.java:344)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
RemoteTestRunner.java:196)

The brackets look ok to me.

[Mark Proctor]

That's illegal syntax, surprised if it worked before. 'eval' is a
conditional element, it cannot be nested inside a Column:
TestParam(s : value -> (s != null) )

BTW null tests work, you can just do:
TestParam(s == null)

If you wanted to use:
TestParam(s : value )
eval(s == null)

Mark
Paul Smith wrote:

> Hi Guys,
>
> I've just put RC2 in place but now rules that did work with RC1 don't build
> any more. An example is as follows:
>
> package testing
>
> import testing.TestParam
>
> rule "testEval"
>
>     when
>         TestParam(s : value -> eval(s != null))
>     then
>         System.out.println("Do something");
> end
>
> When I do the addPackage I get the following:
>
> org.drools.rule.InvalidRulePackage: unknown:8:25 mismatched token:
> [@32,116:119='eval',<56>,8:25]; expecting type '('
>
>     at org.drools.rule.Package.checkValidity(Package.java:378)
>     at org.drools.reteoo.RuleBaseImpl.addPackage(RuleBaseImpl.java:303)
>     at testing.EvalTest.testFunction(EvalTest.java:23)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>     at java.lang.reflect.Method.invoke(Unknown Source)
>     at junit.framework.TestCase.runTest(TestCase.java:154)
>     at junit.framework.TestCase.runBare(TestCase.java:127)
>     at junit.framework.TestResult$1.protect(TestResult.java:106)
>     at junit.framework.TestResult.runProtected(TestResult.java:124)
>     at junit.framework.TestResult.run(TestResult.java:109)
>     at junit.framework.TestCase.run(TestCase.java:118)
>     at junit.framework.TestSuite.runTest(TestSuite.java:208)
>     at junit.framework.TestSuite.run(TestSuite.java:203)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
> RemoteTestRunner.java:478)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
> RemoteTestRunner.java:344)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
> RemoteTestRunner.java:196)
>
> The brackets look ok to me.
>
>  

[Paul Smith-3]

Cool. That makes it a bit more simple. I think I may have wrapped it in an
eval because I was having trouble with the null.

Thanks

On 4/17/06, Mark Proctor <[hidden email]> wrote:

>
> That's illegal syntax, surprised if it worked before. 'eval' is a
> conditional element, it cannot be nested inside a Column:
> TestParam(s : value -> (s != null) )
>
> BTW null tests work, you can just do:
> TestParam(s == null)
>
> If you wanted to use:
> TestParam(s : value )
> eval(s == null)
>
> Mark
> Paul Smith wrote:
> > Hi Guys,
> >
> > I've just put RC2 in place but now rules that did work with RC1 don't
> build
> > any more. An example is as follows:
> >
> > package testing
> >
> > import testing.TestParam
> >
> > rule "testEval"
> >
> >     when
> >         TestParam(s : value -> eval(s != null))
> >     then
> >         System.out.println("Do something");
> > end
> >
> > When I do the addPackage I get the following:
> >
> > org.drools.rule.InvalidRulePackage: unknown:8:25 mismatched token:
> > [@32,116:119='eval',<56>,8:25]; expecting type '('
> >
> >     at org.drools.rule.Package.checkValidity(Package.java:378)
> >     at org.drools.reteoo.RuleBaseImpl.addPackage(RuleBaseImpl.java:303)
> >     at testing.EvalTest.testFunction(EvalTest.java:23)
> >     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> >     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> >     at java.lang.reflect.Method.invoke(Unknown Source)
> >     at junit.framework.TestCase.runTest(TestCase.java:154)
> >     at junit.framework.TestCase.runBare(TestCase.java:127)
> >     at junit.framework.TestResult$1.protect(TestResult.java:106)
> >     at junit.framework.TestResult.runProtected(TestResult.java:124)
> >     at junit.framework.TestResult.run(TestResult.java:109)
> >     at junit.framework.TestCase.run(TestCase.java:118)
> >     at junit.framework.TestSuite.runTest(TestSuite.java:208)
> >     at junit.framework.TestSuite.run(TestSuite.java:203)
> >     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
> > RemoteTestRunner.java:478)
> >     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
> > RemoteTestRunner.java:344)
> >     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
> > RemoteTestRunner.java:196)
> >
> > The brackets look ok to me.
> >
> >
>
>

[Yuesong Wang]

Thanks for the great job on RC2. Solved a lot of my
problem :)

The following rule, however, does not work in RC2
anymore...

  package com.sample
  import com.sample.DroolsTest.Message;
  rule "Hello World"
    when
      m : Message( status == Message.HELLO )
      Message( message == "Hello World" )
    then
      System.out.println( "fired" );
  end

So the field constraints have to be in the sample
column? like

  m:Message(status==0, message=="Hello World")

That is probably no good, especially for someone who
wants to use DSL and map individul conditions to
separate sentences.

Yuesong

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

[Mark Proctor]

  package com.sample
  import com.sample.DroolsTest.Message;
  rule "Hello World"
    when
      m : Message( status == Message.HELLO )
      Message( message == "Hello World" )
    then
      System.out.println( "fired" );
  end

That's filtering on two columns, its like doing this in SQL:
select * from Message, Message
Not what most people want. This hasn't changed in any of the releases  
in Drools 3.0

Mark

Yuesong Wang wrote:

> Thanks for the great job on RC2. Solved a lot of my
> problem :)
>
> The following rule, however, does not work in RC2
> anymore...
>
>   package com.sample
>   import com.sample.DroolsTest.Message;
>   rule "Hello World"
>     when
>       m : Message( status == Message.HELLO )
>       Message( message == "Hello World" )
>     then
>       System.out.println( "fired" );
>   end
>
> So the field constraints have to be in the sample
> column? like
>
>   m:Message(status==0, message=="Hello World")
>
> That is probably no good, especially for someone who
> wants to use DSL and map individul conditions to
> separate sentences.
>
> Yuesong
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com 
>
>
>  

[Edson Tirelli]

   Actually, there is one thing that changed and might affect this use case:
it is the filter on identity cross product.

   Before RC2, if you had a Rule with 2 columns of the same type, like the
rule you wrote bellow, every object in the working memory of that type,
would try to match against itself. So, for instance, if you had asserted two
messages (m1 and m2) in the working memory for this rule, the activations
would be:

[m1, m1]
[m1, m2]
[m2, m1]
[m2, m2]

   In RC2, we added an identity removal constraint to not allow identity
activations like [m1, m1] and [m2, m2].

   So, what is probably happening to you is that you are asserting a single
message object in the working memory. Before RC2, it would create an
activation for [m1, m1] and now it does not creates anymore.
   As Mark said, this is probably and error when writing the rule, as the
rule should have only one column, not two. A better way to write this rule
would be:

   rule "Hello World"
     when
       m : Message( status == Message.HELLO, message == "Hello World" )
     then
       System.out.println( "fired" );
   end

    This way, each single message object asserted into working memory that
matches the constraints, will cause an activation.

   []s
   Edson


----- Original Message -----
From: "Mark Proctor" <[hidden email]>
To: <[hidden email]>
Sent: Monday, April 17, 2006 4:26 PM
Subject: Re: [drools-user] RC2

>   package com.sample
>   import com.sample.DroolsTest.Message;
>   rule "Hello World"
>     when
>       m : Message( status == Message.HELLO )
>       Message( message == "Hello World" )
>     then
>       System.out.println( "fired" );
>   end
>
> That's filtering on two columns, its like doing this in SQL:
> select * from Message, Message
> Not what most people want. This hasn't changed in any of the releases
> in Drools 3.0
>
> Mark
>
> Yuesong Wang wrote:
> > Thanks for the great job on RC2. Solved a lot of my
> > problem :)
> >
> > The following rule, however, does not work in RC2
> > anymore...
> >
> >   package com.sample
> >   import com.sample.DroolsTest.Message;
> >   rule "Hello World"
> >     when
> >       m : Message( status == Message.HELLO )
> >       Message( message == "Hello World" )
> >     then
> >       System.out.println( "fired" );
> >   end
> >
> > So the field constraints have to be in the sample
> > column? like
> >
> >   m:Message(status==0, message=="Hello World")
> >
> > That is probably no good, especially for someone who
> > wants to use DSL and map individul conditions to
> > separate sentences.
> >
> > Yuesong
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> >
> >
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.2/314 - Release Date: 16/4/2006
>
>

[Michael Neale]

OK I thought this may cause an issue.

As Yuesong said, it was handy to be able to spread conditions across lines
(sentences in DSLs) as it made it more readable. Now when we do that, it
won't work.
So what do we do? Allow the identity cross product?
In simple cases, yes it does make things easier, but I think in practice,
the benefit of removing the cross product will save people a lot of hassle.

The case Yuesong mentions is valid though, as in you may want to just keep
adding "stand alone" constraints to a fact. But in that case, (with RC1) if
you added one more Message to working memory, then suddenly you would see
"wierd" behaviour (as you are getting all possible matches). Hence I think
that removing the cross products is probably the most desirable behaviour.
And also, it is possible to do what is required by Yuesong via a work around
with "eval" adding more constraints - its not optimal (it is a work around)
but in simple cases it may be fine.
As always if we get enough pressure, we can make this configurable
behaviour. But from Drools 2.x experience, we get a LOT of confusion over
the cross product stuff, and this saves a lot of hassle.


On 4/18/06, Edson Tirelli <[hidden email]> wrote:

>
>    Actually, there is one thing that changed and might affect this use
> case:
> it is the filter on identity cross product.
>
>    Before RC2, if you had a Rule with 2 columns of the same type, like the
> rule you wrote bellow, every object in the working memory of that type,
> would try to match against itself. So, for instance, if you had asserted
> two
> messages (m1 and m2) in the working memory for this rule, the activations
> would be:
>
> [m1, m1]
> [m1, m2]
> [m2, m1]
> [m2, m2]
>
>    In RC2, we added an identity removal constraint to not allow identity
> activations like [m1, m1] and [m2, m2].
>
>    So, what is probably happening to you is that you are asserting a
> single
> message object in the working memory. Before RC2, it would create an
> activation for [m1, m1] and now it does not creates anymore.
>    As Mark said, this is probably and error when writing the rule, as the
> rule should have only one column, not two. A better way to write this rule
> would be:
>
>    rule "Hello World"
>      when
>        m : Message( status == Message.HELLO, message == "Hello World" )
>      then
>        System.out.println( "fired" );
>    end
>
>     This way, each single message object asserted into working memory that
> matches the constraints, will cause an activation.
>
>    []s
>    Edson
>
>
> ----- Original Message -----
> From: "Mark Proctor" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, April 17, 2006 4:26 PM
> Subject: Re: [drools-user] RC2
>
>
> >   package com.sample
> >   import com.sample.DroolsTest.Message;
> >   rule "Hello World"
> >     when
> >       m : Message( status == Message.HELLO )
> >       Message( message == "Hello World" )
> >     then
> >       System.out.println( "fired" );
> >   end
> >
> > That's filtering on two columns, its like doing this in SQL:
> > select * from Message, Message
> > Not what most people want. This hasn't changed in any of the releases
> > in Drools 3.0
> >
> > Mark
> >
> > Yuesong Wang wrote:
> > > Thanks for the great job on RC2. Solved a lot of my
> > > problem :)
> > >
> > > The following rule, however, does not work in RC2
> > > anymore...
> > >
> > >   package com.sample
> > >   import com.sample.DroolsTest.Message;
> > >   rule "Hello World"
> > >     when
> > >       m : Message( status == Message.HELLO )
> > >       Message( message == "Hello World" )
> > >     then
> > >       System.out.println( "fired" );
> > >   end
> > >
> > > So the field constraints have to be in the sample
> > > column? like
> > >
> > >   m:Message(status==0, message=="Hello World")
> > >
> > > That is probably no good, especially for someone who
> > > wants to use DSL and map individul conditions to
> > > separate sentences.
> > >
> > > Yuesong
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam?  Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > >
> > >
> > >
> >
> >
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.385 / Virus Database: 268.4.2/314 - Release Date: 16/4/2006
> >
> >
>
>

[Yuesong Wang]

Thanks for the replies. I'm just pointing out a
difference in behavior. What Edson said explained why.
Given that explanation though, I'm afraid this example
rule from the wiki is no longer what it is meant to
demonstrate:

rule "Hello World"
  when
    m : Message(list contains "hello")
    Message(message == "hola")
    Message(number > 40)
    Message(birthday > "10-Jul-1974")
    Message(message matches ".*ho.*")
  then
    System.out.println("hello world " +
m.getMessage());
    m.setFired(true);
end

If I understand it correctly, for this rule to fire,
five Message objects need to be inserted.

I agree with Michael that eval can be used as a
workaround.

Yuesong

--- Michael Neale <[hidden email]> wrote:

> OK I thought this may cause an issue.
>
> As Yuesong said, it was handy to be able to spread
> conditions across lines
> (sentences in DSLs) as it made it more readable. Now
> when we do that, it
> won't work.
> So what do we do? Allow the identity cross product?
> In simple cases, yes it does make things easier, but
> I think in practice,
> the benefit of removing the cross product will save
> people a lot of hassle.
>
> The case Yuesong mentions is valid though, as in you
> may want to just keep
> adding "stand alone" constraints to a fact. But in
> that case, (with RC1) if
> you added one more Message to working memory, then
> suddenly you would see
> "wierd" behaviour (as you are getting all possible
> matches). Hence I think
> that removing the cross products is probably the
> most desirable behaviour.
> And also, it is possible to do what is required by
> Yuesong via a work around
> with "eval" adding more constraints - its not
> optimal (it is a work around)
> but in simple cases it may be fine.
> As always if we get enough pressure, we can make
> this configurable
> behaviour. But from Drools 2.x experience, we get a
> LOT of confusion over
> the cross product stuff, and this saves a lot of
> hassle.
>
>
> On 4/18/06, Edson Tirelli
> <[hidden email]> wrote:
> >
> >    Actually, there is one thing that changed and
> might affect this use
> > case:
> > it is the filter on identity cross product.
> >
> >    Before RC2, if you had a Rule with 2 columns of
> the same type, like the
> > rule you wrote bellow, every object in the working
> memory of that type,
> > would try to match against itself. So, for
> instance, if you had asserted
> > two
> > messages (m1 and m2) in the working memory for
> this rule, the activations
> > would be:
> >
> > [m1, m1]
> > [m1, m2]
> > [m2, m1]
> > [m2, m2]
> >
> >    In RC2, we added an identity removal constraint
> to not allow identity
> > activations like [m1, m1] and [m2, m2].
> >
> >    So, what is probably happening to you is that
> you are asserting a
> > single
> > message object in the working memory. Before RC2,
> it would create an
> > activation for [m1, m1] and now it does not
> creates anymore.
> >    As Mark said, this is probably and error when
> writing the rule, as the
> > rule should have only one column, not two. A
> better way to write this rule
> > would be:
> >
> >    rule "Hello World"
> >      when
> >        m : Message( status == Message.HELLO,
> message == "Hello World" )
> >      then
> >        System.out.println( "fired" );
> >    end
> >
> >     This way, each single message object asserted
> into working memory that
> > matches the constraints, will cause an activation.
> >
> >    []s
> >    Edson
> >
> >
> > ----- Original Message -----
> > From: "Mark Proctor" <[hidden email]>
> > To: <[hidden email]>
> > Sent: Monday, April 17, 2006 4:26 PM
> > Subject: Re: [drools-user] RC2
> >
> >
> > >   package com.sample
> > >   import com.sample.DroolsTest.Message;
> > >   rule "Hello World"
> > >     when
> > >       m : Message( status == Message.HELLO )
> > >       Message( message == "Hello World" )
> > >     then
> > >       System.out.println( "fired" );
> > >   end
> > >
> > > That's filtering on two columns, its like doing
> this in SQL:
> > > select * from Message, Message
> > > Not what most people want. This hasn't changed
> in any of the releases
> > > in Drools 3.0
> > >
> > > Mark
> > >
> > > Yuesong Wang wrote:
> > > > Thanks for the great job on RC2. Solved a lot
> of my
> > > > problem :)
> > > >
> > > > The following rule, however, does not work in
> RC2
> > > > anymore...
> > > >
> > > >   package com.sample
> > > >   import com.sample.DroolsTest.Message;
> > > >   rule "Hello World"
> > > >     when
> > > >       m : Message( status == Message.HELLO )
> > > >       Message( message == "Hello World" )
> > > >     then
> > > >       System.out.println( "fired" );
> > > >   end
> > > >
> > > > So the field constraints have to be in the
> sample
> > > > column? like
> > > >
> > > >   m:Message(status==0, message=="Hello World")
> > > >
> > > > That is probably no good, especially for
> someone who
> > > > wants to use DSL and map individul conditions
> to
> > > > separate sentences.
> > > >
> > > > Yuesong
> > > >
> > > >
> __________________________________________________
> > > > Do You Yahoo!?
> > > > Tired of spam?  Yahoo! Mail has the best spam
> protection around
> > > > http://mail.yahoo.com
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > No virus found in this incoming message.
> > > Checked by AVG Free Edition.
> > > Version: 7.1.385 / Virus Database: 268.4.2/314 -
> Release Date: 16/4/2006
> > >
> > >
> >
> >
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

[Mitch Christensen-2]

Hey,

Quite often I want to work with 'temporary' facts that I often refer to as
'indicator' facts.  With Jess I used to use ordered facts for this purpose.
In Drools, do I have to create a Java bean for every such case?

What if I wanted to do the following,

then
        assert("MapExists");
end

How would I match this fact elsewhere?

-Mitch

[Mark Proctor]

You can't. I would make a JavaBean wrapper with a single field. That
field can be a String or take Enum values - later is better and faster,
Strings are more flexiible.

Mark

Mitch Christensen wrote:

> Hey,
>
> Quite often I want to work with 'temporary' facts that I often refer to as
> 'indicator' facts.  With Jess I used to use ordered facts for this purpose.
> In Drools, do I have to create a Java bean for every such case?
>
> What if I wanted to do the following,
>
> then
> assert("MapExists");
> end
>
> How would I match this fact elsewhere?
>
> -Mitch
>
>
>
>  

[Michael Neale]

correct, 5 objects, and "m" would be bound to the first one. Also, it would
happen for all the combinations of the 5 messages (probably not exactly what
you want !).

I have updated the wiki (wiki is being edited as more and more doco goes
into the manual). As always, feel free to add to the wiki, corrections,
notes, gotchas etc... it all helps !

Michael.

On 4/18/06, Yuesong Wang <[hidden email]> wrote:

>
> Thanks for the replies. I'm just pointing out a
> difference in behavior. What Edson said explained why.
> Given that explanation though, I'm afraid this example
> rule from the wiki is no longer what it is meant to
> demonstrate:
>
> rule "Hello World"
>   when
>     m : Message(list contains "hello")
>     Message(message == "hola")
>     Message(number > 40)
>     Message(birthday > "10-Jul-1974")
>     Message(message matches ".*ho.*")
>   then
>     System.out.println("hello world " +
> m.getMessage());
>     m.setFired(true);
> end
>
> If I understand it correctly, for this rule to fire,
> five Message objects need to be inserted.
>
> I agree with Michael that eval can be used as a
> workaround.
>
> Yuesong
>
> --- Michael Neale <[hidden email]> wrote:
>
> > OK I thought this may cause an issue.
> >
> > As Yuesong said, it was handy to be able to spread
> > conditions across lines
> > (sentences in DSLs) as it made it more readable. Now
> > when we do that, it
> > won't work.
> > So what do we do? Allow the identity cross product?
> > In simple cases, yes it does make things easier, but
> > I think in practice,
> > the benefit of removing the cross product will save
> > people a lot of hassle.
> >
> > The case Yuesong mentions is valid though, as in you
> > may want to just keep
> > adding "stand alone" constraints to a fact. But in
> > that case, (with RC1) if
> > you added one more Message to working memory, then
> > suddenly you would see
> > "wierd" behaviour (as you are getting all possible
> > matches). Hence I think
> > that removing the cross products is probably the
> > most desirable behaviour.
> > And also, it is possible to do what is required by
> > Yuesong via a work around
> > with "eval" adding more constraints - its not
> > optimal (it is a work around)
> > but in simple cases it may be fine.
> > As always if we get enough pressure, we can make
> > this configurable
> > behaviour. But from Drools 2.x experience, we get a
> > LOT of confusion over
> > the cross product stuff, and this saves a lot of
> > hassle.
> >
> >
> > On 4/18/06, Edson Tirelli
> > <[hidden email]> wrote:
> > >
> > >    Actually, there is one thing that changed and
> > might affect this use
> > > case:
> > > it is the filter on identity cross product.
> > >
> > >    Before RC2, if you had a Rule with 2 columns of
> > the same type, like the
> > > rule you wrote bellow, every object in the working
> > memory of that type,
> > > would try to match against itself. So, for
> > instance, if you had asserted
> > > two
> > > messages (m1 and m2) in the working memory for
> > this rule, the activations
> > > would be:
> > >
> > > [m1, m1]
> > > [m1, m2]
> > > [m2, m1]
> > > [m2, m2]
> > >
> > >    In RC2, we added an identity removal constraint
> > to not allow identity
> > > activations like [m1, m1] and [m2, m2].
> > >
> > >    So, what is probably happening to you is that
> > you are asserting a
> > > single
> > > message object in the working memory. Before RC2,
> > it would create an
> > > activation for [m1, m1] and now it does not
> > creates anymore.
> > >    As Mark said, this is probably and error when
> > writing the rule, as the
> > > rule should have only one column, not two. A
> > better way to write this rule
> > > would be:
> > >
> > >    rule "Hello World"
> > >      when
> > >        m : Message( status == Message.HELLO,
> > message == "Hello World" )
> > >      then
> > >        System.out.println( "fired" );
> > >    end
> > >
> > >     This way, each single message object asserted
> > into working memory that
> > > matches the constraints, will cause an activation.
> > >
> > >    []s
> > >    Edson
> > >
> > >
> > > ----- Original Message -----
> > > From: "Mark Proctor" <[hidden email]>
> > > To: <[hidden email]>
> > > Sent: Monday, April 17, 2006 4:26 PM
> > > Subject: Re: [drools-user] RC2
> > >
> > >
> > > >   package com.sample
> > > >   import com.sample.DroolsTest.Message;
> > > >   rule "Hello World"
> > > >     when
> > > >       m : Message( status == Message.HELLO )
> > > >       Message( message == "Hello World" )
> > > >     then
> > > >       System.out.println( "fired" );
> > > >   end
> > > >
> > > > That's filtering on two columns, its like doing
> > this in SQL:
> > > > select * from Message, Message
> > > > Not what most people want. This hasn't changed
> > in any of the releases
> > > > in Drools 3.0
> > > >
> > > > Mark
> > > >
> > > > Yuesong Wang wrote:
> > > > > Thanks for the great job on RC2. Solved a lot
> > of my
> > > > > problem :)
> > > > >
> > > > > The following rule, however, does not work in
> > RC2
> > > > > anymore...
> > > > >
> > > > >   package com.sample
> > > > >   import com.sample.DroolsTest.Message;
> > > > >   rule "Hello World"
> > > > >     when
> > > > >       m : Message( status == Message.HELLO )
> > > > >       Message( message == "Hello World" )
> > > > >     then
> > > > >       System.out.println( "fired" );
> > > > >   end
> > > > >
> > > > > So the field constraints have to be in the
> > sample
> > > > > column? like
> > > > >
> > > > >   m:Message(status==0, message=="Hello World")
> > > > >
> > > > > That is probably no good, especially for
> > someone who
> > > > > wants to use DSL and map individul conditions
> > to
> > > > > separate sentences.
> > > > >
> > > > > Yuesong
> > > > >
> > > > >
> > __________________________________________________
> > > > > Do You Yahoo!?
> > > > > Tired of spam?  Yahoo! Mail has the best spam
> > protection around
> > > > > http://mail.yahoo.com
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > No virus found in this incoming message.
> > > > Checked by AVG Free Edition.
> > > > Version: 7.1.385 / Virus Database: 268.4.2/314 -
> > Release Date: 16/4/2006
> > > >
> > > >
> > >
> > >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

[Michael Neale]

assert(new TempFact("MapExists")); something like that. You can use TempFact
over and over. If you intern the string in the TempFact bean, then it could
be pretty fast to check (as the JVM will do an identity compare before a
string char compare I think). You only need to create it once.



On 4/19/06, Mitch Christensen <[hidden email]> wrote:

>
> Hey,
>
> Quite often I want to work with 'temporary' facts that I often refer to as
> 'indicator' facts.  With Jess I used to use ordered facts for this
> purpose.
> In Drools, do I have to create a Java bean for every such case?
>
> What if I wanted to do the following,
>
> then
>         assert("MapExists");
> end
>
> How would I match this fact elsewhere?
>
> -Mitch
>
>

[Russ Egan-2]

Generally, to capture transient facts like this, is it more efficient to
create new beans and assert them, or more efficient to create additional
properties on existing beans?

for example:

assert(new TempFact("MapExists"));

...versus...

mapController.setMapExists(true);
modify(mapController);

I assume there is some memory advantage to the properties, but are there
any performance differences?

Hello Michael,

> assert(new TempFact("MapExists")); something like that. You can use
> TempFac
> t
> over and over. If you intern the string in the TempFact bean, then it
> could
> be pretty fast to check (as the JVM will do an identity compare before
> a
> string char compare I think). You only need to create it once.

[work_registries]

I want to express my concerns about "hardcoding" a filter of identity
cross products. Someone might want a rule to fire for an identity
activation. And while you can write a RHS that does the filters job, you
can't write a RHS that gets you the identity activation if the filter's
active.

Probably introduce it as a rule attribute, with default value for filter
being activated, if it really is necessary to have such a filter at all.

There is nothing like SELECT * FROM A AS a, A AS b WHERE a.ROWID !=
b.ROWID hardcoded in SQL either.

Juergen.

Michael Neale wrote:

> OK I thought this may cause an issue.
>
> As Yuesong said, it was handy to be able to spread conditions across lines
> (sentences in DSLs) as it made it more readable. Now when we do that, it
> won't work.
> So what do we do? Allow the identity cross product?
> In simple cases, yes it does make things easier, but I think in practice,
> the benefit of removing the cross product will save people a lot of hassle.
>
> The case Yuesong mentions is valid though, as in you may want to just keep
> adding "stand alone" constraints to a fact. But in that case, (with RC1) if
> you added one more Message to working memory, then suddenly you would see
> "wierd" behaviour (as you are getting all possible matches). Hence I think
> that removing the cross products is probably the most desirable behaviour.
> And also, it is possible to do what is required by Yuesong via a work around
> with "eval" adding more constraints - its not optimal (it is a work around)
> but in simple cases it may be fine.
> As always if we get enough pressure, we can make this configurable
> behaviour. But from Drools 2.x experience, we get a LOT of confusion over
> the cross product stuff, and this saves a lot of hassle.
>
>
> On 4/18/06, Edson Tirelli <[hidden email]> wrote:
>
>>   Actually, there is one thing that changed and might affect this use
>>case:
>>it is the filter on identity cross product.
>>
>>   Before RC2, if you had a Rule with 2 columns of the same type, like the
>>rule you wrote bellow, every object in the working memory of that type,
>>would try to match against itself. So, for instance, if you had asserted
>>two
>>messages (m1 and m2) in the working memory for this rule, the activations
>>would be:
>>
>>[m1, m1]
>>[m1, m2]
>>[m2, m1]
>>[m2, m2]
>>
>>   In RC2, we added an identity removal constraint to not allow identity
>>activations like [m1, m1] and [m2, m2].
>>
>>   So, what is probably happening to you is that you are asserting a
>>single
>>message object in the working memory. Before RC2, it would create an
>>activation for [m1, m1] and now it does not creates anymore.
>>   As Mark said, this is probably and error when writing the rule, as the
>>rule should have only one column, not two. A better way to write this rule
>>would be:
>>
>>   rule "Hello World"
>>     when
>>       m : Message( status == Message.HELLO, message == "Hello World" )
>>     then
>>       System.out.println( "fired" );
>>   end
>>
>>    This way, each single message object asserted into working memory that
>>matches the constraints, will cause an activation.
>>
>>   []s
>>   Edson
>>
>>
>>----- Original Message -----
>>From: "Mark Proctor" <[hidden email]>
>>To: <[hidden email]>
>>Sent: Monday, April 17, 2006 4:26 PM
>>Subject: Re: [drools-user] RC2
>>
>>
>>
>>>  package com.sample
>>>  import com.sample.DroolsTest.Message;
>>>  rule "Hello World"
>>>    when
>>>      m : Message( status == Message.HELLO )
>>>      Message( message == "Hello World" )
>>>    then
>>>      System.out.println( "fired" );
>>>  end
>>>
>>>That's filtering on two columns, its like doing this in SQL:
>>>select * from Message, Message
>>>Not what most people want. This hasn't changed in any of the releases
>>>in Drools 3.0
>>>
>>>Mark
>>>
>>>Yuesong Wang wrote:
>>>
>>>>Thanks for the great job on RC2. Solved a lot of my
>>>>problem :)
>>>>
>>>>The following rule, however, does not work in RC2
>>>>anymore...
>>>>
>>>>  package com.sample
>>>>  import com.sample.DroolsTest.Message;
>>>>  rule "Hello World"
>>>>    when
>>>>      m : Message( status == Message.HELLO )
>>>>      Message( message == "Hello World" )
>>>>    then
>>>>      System.out.println( "fired" );
>>>>  end
>>>>
>>>>So the field constraints have to be in the sample
>>>>column? like
>>>>
>>>>  m:Message(status==0, message=="Hello World")
>>>>
>>>>That is probably no good, especially for someone who
>>>>wants to use DSL and map individul conditions to
>>>>separate sentences.
>>>>
>>>>Yuesong
>>>>
>>>>__________________________________________________
>>>>Do You Yahoo!?
>>>>Tired of spam?  Yahoo! Mail has the best spam protection around
>>>>http://mail.yahoo.com
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>--
>>>No virus found in this incoming message.
>>>Checked by AVG Free Edition.
>>>Version: 7.1.385 / Virus Database: 268.4.2/314 - Release Date: 16/4/2006

[Mark Proctor]

Juergen,

You are right in that SQL doesn't remove identiy equals cross products.  
We found that people continually had problems understanding and
constraining cross products. Further other engines do this as standard;
so it seemed to make sense that we do. If someone can provide me with a
real use case and prove the need to make this optional I will consider
adding a rule attribute in 3.1

Mark
Juergen wrote:

> I want to express my concerns about "hardcoding" a filter of identity
> cross products. Someone might want a rule to fire for an identity
> activation. And while you can write a RHS that does the filters job,
> you can't write a RHS that gets you the identity activation if the
> filter's active.
>
> Probably introduce it as a rule attribute, with default value for
> filter being activated, if it really is necessary to have such a
> filter at all.
>
> There is nothing like SELECT * FROM A AS a, A AS b WHERE a.ROWID !=
> b.ROWID hardcoded in SQL either.
>
> Juergen.
>
> Michael Neale wrote:
>> OK I thought this may cause an issue.
>>
>> As Yuesong said, it was handy to be able to spread conditions across
>> lines
>> (sentences in DSLs) as it made it more readable. Now when we do that, it
>> won't work.
>> So what do we do? Allow the identity cross product?
>> In simple cases, yes it does make things easier, but I think in
>> practice,
>> the benefit of removing the cross product will save people a lot of
>> hassle.
>>
>> The case Yuesong mentions is valid though, as in you may want to just
>> keep
>> adding "stand alone" constraints to a fact. But in that case, (with
>> RC1) if
>> you added one more Message to working memory, then suddenly you would
>> see
>> "wierd" behaviour (as you are getting all possible matches). Hence I
>> think
>> that removing the cross products is probably the most desirable
>> behaviour.
>> And also, it is possible to do what is required by Yuesong via a work
>> around
>> with "eval" adding more constraints - its not optimal (it is a work
>> around)
>> but in simple cases it may be fine.
>> As always if we get enough pressure, we can make this configurable
>> behaviour. But from Drools 2.x experience, we get a LOT of confusion
>> over
>> the cross product stuff, and this saves a lot of hassle.
>>
>>
>> On 4/18/06, Edson Tirelli <[hidden email]> wrote:
>>
>>>   Actually, there is one thing that changed and might affect this use
>>> case:
>>> it is the filter on identity cross product.
>>>
>>>   Before RC2, if you had a Rule with 2 columns of the same type,
>>> like the
>>> rule you wrote bellow, every object in the working memory of that type,
>>> would try to match against itself. So, for instance, if you had
>>> asserted
>>> two
>>> messages (m1 and m2) in the working memory for this rule, the
>>> activations
>>> would be:
>>>
>>> [m1, m1]
>>> [m1, m2]
>>> [m2, m1]
>>> [m2, m2]
>>>
>>>   In RC2, we added an identity removal constraint to not allow identity
>>> activations like [m1, m1] and [m2, m2].
>>>
>>>   So, what is probably happening to you is that you are asserting a
>>> single
>>> message object in the working memory. Before RC2, it would create an
>>> activation for [m1, m1] and now it does not creates anymore.
>>>   As Mark said, this is probably and error when writing the rule, as
>>> the
>>> rule should have only one column, not two. A better way to write
>>> this rule
>>> would be:
>>>
>>>   rule "Hello World"
>>>     when
>>>       m : Message( status == Message.HELLO, message == "Hello World" )
>>>     then
>>>       System.out.println( "fired" );
>>>   end
>>>
>>>    This way, each single message object asserted into working memory
>>> that
>>> matches the constraints, will cause an activation.
>>>
>>>   []s
>>>   Edson
>>>
>>>
>>> ----- Original Message -----
>>> From: "Mark Proctor" <[hidden email]>
>>> To: <[hidden email]>
>>> Sent: Monday, April 17, 2006 4:26 PM
>>> Subject: Re: [drools-user] RC2
>>>
>>>
>>>
>>>>  package com.sample
>>>>  import com.sample.DroolsTest.Message;
>>>>  rule "Hello World"
>>>>    when
>>>>      m : Message( status == Message.HELLO )
>>>>      Message( message == "Hello World" )
>>>>    then
>>>>      System.out.println( "fired" );
>>>>  end
>>>>
>>>> That's filtering on two columns, its like doing this in SQL:
>>>> select * from Message, Message
>>>> Not what most people want. This hasn't changed in any of the releases
>>>> in Drools 3.0
>>>>
>>>> Mark
>>>>
>>>> Yuesong Wang wrote:
>>>>
>>>>> Thanks for the great job on RC2. Solved a lot of my
>>>>> problem :)
>>>>>
>>>>> The following rule, however, does not work in RC2
>>>>> anymore...
>>>>>
>>>>>  package com.sample
>>>>>  import com.sample.DroolsTest.Message;
>>>>>  rule "Hello World"
>>>>>    when
>>>>>      m : Message( status == Message.HELLO )
>>>>>      Message( message == "Hello World" )
>>>>>    then
>>>>>      System.out.println( "fired" );
>>>>>  end
>>>>>
>>>>> So the field constraints have to be in the sample
>>>>> column? like
>>>>>
>>>>>  m:Message(status==0, message=="Hello World")
>>>>>
>>>>> That is probably no good, especially for someone who
>>>>> wants to use DSL and map individul conditions to
>>>>> separate sentences.
>>>>>
>>>>> Yuesong
>>>>>
>>>>> __________________________________________________
>>>>> Do You Yahoo!?
>>>>> Tired of spam?  Yahoo! Mail has the best spam protection around
>>>>> http://mail.yahoo.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> No virus found in this incoming message.
>>>> Checked by AVG Free Edition.
>>>> Version: 7.1.385 / Virus Database: 268.4.2/314 - Release Date:
>>>> 16/4/2006
>
>
>

[Mitch Christensen-2]

I ended up creating and OrderedFact Java object which contains a String
'type' and List 'values' property.

This allows me to do things like,

rule "Create a grocery list"
        when
                not OrderedFact(type == "GroceryList")
        then
                assert(new OrderedFact("GroceryList", new String[] {"peas",
"carrots"}));
end

rule "Add milk if the list contains peas"
        when
                f : OrderedFact(type == "GroceryList", values contains
"peas")
                eval(!f.getValues().contains("milk"))
        then
                f.getValues().add("milk");
end

-Mitch

PS Is there a way to avoid the eval() in the second rule?

-----Original Message-----
From: Michael Neale [mailto:[hidden email]]
Sent: Tuesday, April 18, 2006 5:06 PM
To: [hidden email]
Subject: Re: [drools-user] Indicator (ordered) Facts

assert(new TempFact("MapExists")); something like that. You can use TempFact
over and over. If you intern the string in the TempFact bean, then it could
be pretty fast to check (as the JVM will do an identity compare before a
string char compare I think). You only need to create it once.



On 4/19/06, Mitch Christensen <[hidden email]> wrote:

>
> Hey,
>
> Quite often I want to work with 'temporary' facts that I often refer to as
> 'indicator' facts.  With Jess I used to use ordered facts for this
> purpose.
> In Drools, do I have to create a Java bean for every such case?
>
> What if I wanted to do the following,
>
> then
>         assert("MapExists");
> end
>
> How would I match this fact elsewhere?
>
> -Mitch
>
>

[Russ Egan-2]

Did you try adding extra columns?  Like:

OrderedFact(type == "GroceryList", values contains "peas", values contains
"milk");

Hello Mitch,

> I ended up creating and OrderedFact Java object which contains a
> String 'type' and List 'values' property.
>
> This allows me to do things like,
>
> rule "Create a grocery list"
> when
> not OrderedFact(type == "GroceryList")
> then
> assert(new OrderedFact("GroceryList", new String[] {"peas",
> "carrots"}));
> end
>
> rule "Add milk if the list contains peas"
> when
> f : OrderedFact(type == "GroceryList", values contains
> "peas")
> eval(!f.getValues().contains("milk"))
> then
> f.getValues().add("milk");
> end
> -Mitch
>
> PS Is there a way to avoid the eval() in the second rule?
>
> -----Original Message-----
>> From: Michael Neale [mailto:[hidden email]]
>> Sent: Tuesday, April 18, 2006 5:06 PM
>> To: [hidden email]
>> Subject: Re: [drools-user] Indicator (ordered) Facts
>> assert(new TempFact("MapExists")); something like that. You can use
>> TempFact over and over. If you intern the string in the TempFact
>> bean, then it could be pretty fast to check (as the JVM will do an
>> identity compare before a string char compare I think). You only need
>> to create it once.
>>
>> On 4/19/06, Mitch Christensen <[hidden email]> wrote:
>>
>> Hey,
>>
>> Quite often I want to work with 'temporary' facts that I often refer
>> to as
>> 'indicator' facts.  With Jess I used to use ordered facts for this
>> purpose.
>> In Drools, do I have to create a Java bean for every such case?
>> What if I wanted to do the following,
>>
>> then
>> assert("MapExists");
>> end
>> How would I match this fact elsewhere?
>>
>> -Mitch
>>

[Mitch Christensen-2]

I couldn't find a way to say 'values not contains "milk"', hence the eval()
and my subsequent request for assistance.

Does such syntax exist?

-Mitch

-----Original Message-----
From: news [mailto:[hidden email]] On Behalf Of Russ Egan
Sent: Wednesday, April 19, 2006 10:16 AM
To: [hidden email]
Subject: RE: [drools-user] Indicator (ordered) Facts

Did you try adding extra columns?  Like:

OrderedFact(type == "GroceryList", values contains "peas", values contains
"milk");

Hello Mitch,

> I ended up creating and OrderedFact Java object which contains a
> String 'type' and List 'values' property.
>
> This allows me to do things like,
>
> rule "Create a grocery list"
> when
> not OrderedFact(type == "GroceryList")
> then
> assert(new OrderedFact("GroceryList", new String[] {"peas",
> "carrots"}));
> end
>
> rule "Add milk if the list contains peas"
> when
> f : OrderedFact(type == "GroceryList", values contains
> "peas")
> eval(!f.getValues().contains("milk"))
> then
> f.getValues().add("milk");
> end
> -Mitch
>
> PS Is there a way to avoid the eval() in the second rule?
>
> -----Original Message-----
>> From: Michael Neale [mailto:[hidden email]]
>> Sent: Tuesday, April 18, 2006 5:06 PM
>> To: [hidden email]
>> Subject: Re: [drools-user] Indicator (ordered) Facts
>> assert(new TempFact("MapExists")); something like that. You can use
>> TempFact over and over. If you intern the string in the TempFact
>> bean, then it could be pretty fast to check (as the JVM will do an
>> identity compare before a string char compare I think). You only need
>> to create it once.
>>
>> On 4/19/06, Mitch Christensen <[hidden email]> wrote:
>>
>> Hey,
>>
>> Quite often I want to work with 'temporary' facts that I often refer
>> to as
>> 'indicator' facts.  With Jess I used to use ordered facts for this
>> purpose.
>> In Drools, do I have to create a Java bean for every such case?
>> What if I wanted to do the following,
>>
>> then
>> assert("MapExists");
>> end
>> How would I match this fact elsewhere?
>>
>> -Mitch
>>

[Mark Proctor]

Mitch yes I think thats the case, can you open a jira for that - so we
can put it into 3.1

Mark
Mitch Christensen wrote:

> I couldn't find a way to say 'values not contains "milk"', hence the eval()
> and my subsequent request for assistance.
>
> Does such syntax exist?
>
> -Mitch
>
> -----Original Message-----
> From: news [mailto:[hidden email]] On Behalf Of Russ Egan
> Sent: Wednesday, April 19, 2006 10:16 AM
> To: [hidden email]
> Subject: RE: [drools-user] Indicator (ordered) Facts
>
> Did you try adding extra columns?  Like:
>
> OrderedFact(type == "GroceryList", values contains "peas", values contains
> "milk");
>
> Hello Mitch,
>
>  
>> I ended up creating and OrderedFact Java object which contains a
>> String 'type' and List 'values' property.
>>
>> This allows me to do things like,
>>
>> rule "Create a grocery list"
>> when
>> not OrderedFact(type == "GroceryList")
>> then
>> assert(new OrderedFact("GroceryList", new String[] {"peas",
>> "carrots"}));
>> end
>>
>> rule "Add milk if the list contains peas"
>> when
>> f : OrderedFact(type == "GroceryList", values contains
>> "peas")
>> eval(!f.getValues().contains("milk"))
>> then
>> f.getValues().add("milk");
>> end
>> -Mitch
>>
>> PS Is there a way to avoid the eval() in the second rule?
>>
>> -----Original Message-----
>>    
>>> From: Michael Neale [mailto:[hidden email]]
>>> Sent: Tuesday, April 18, 2006 5:06 PM
>>> To: [hidden email]
>>> Subject: Re: [drools-user] Indicator (ordered) Facts
>>> assert(new TempFact("MapExists")); something like that. You can use
>>> TempFact over and over. If you intern the string in the TempFact
>>> bean, then it could be pretty fast to check (as the JVM will do an
>>> identity compare before a string char compare I think). You only need
>>> to create it once.
>>>
>>> On 4/19/06, Mitch Christensen <[hidden email]> wrote:
>>>
>>> Hey,
>>>
>>> Quite often I want to work with 'temporary' facts that I often refer
>>> to as
>>> 'indicator' facts.  With Jess I used to use ordered facts for this
>>> purpose.
>>> In Drools, do I have to create a Java bean for every such case?
>>> What if I wanted to do the following,
>>>
>>> then
>>> assert("MapExists");
>>> end
>>> How would I match this fact elsewhere?
>>>
>>> -Mitch
>>>
>>>      
>
>
>
>
>
>  

[Russ Egan-2]

Doh, sorry. didn't see the !

Hello Mitch,

> I couldn't find a way to say 'values not contains "milk"', hence the
> eval() and my subsequent request for assistance.
>
> Does such syntax exist?
>
> -Mitch
>
> -----Original Message-----
>> From: news [mailto:[hidden email]] On Behalf Of Russ Egan
>> Sent: Wednesday, April 19, 2006 10:16 AM
>> To: [hidden email]
>> Subject: RE: [drools-user] Indicator (ordered) Facts
>> Did you try adding extra columns?  Like:
>>
>> OrderedFact(type == "GroceryList", values contains "peas", values
>> contains "milk");
>>
>> Hello Mitch,
>>
>> I ended up creating and OrderedFact Java object which contains a
>> String 'type' and List 'values' property.
>>
>> This allows me to do things like,
>>
>> rule "Create a grocery list"
>> when
>> not OrderedFact(type == "GroceryList")
>> then
>> assert(new OrderedFact("GroceryList", new String[] {"peas",
>> "carrots"}));
>> end
>> rule "Add milk if the list contains peas"
>> when
>> f : OrderedFact(type == "GroceryList", values contains
>> "peas")
>> eval(!f.getValues().contains("milk"))
>> then
>> f.getValues().add("milk");
>> end
>> -Mitch
>> PS Is there a way to avoid the eval() in the second rule?
>>
>> -----Original Message-----
>>
>> From: Michael Neale [mailto:[hidden email]]
>> Sent: Tuesday, April 18, 2006 5:06 PM
>> To: [hidden email]
>> Subject: Re: [drools-user] Indicator (ordered) Facts
>> assert(new TempFact("MapExists")); something like that. You can use
>> TempFact over and over. If you intern the string in the TempFact
>> bean, then it could be pretty fast to check (as the JVM will do an
>> identity compare before a string char compare I think). You only need
>> to create it once.
>> On 4/19/06, Mitch Christensen <[hidden email]> wrote:
>>
>> Hey,
>>
>> Quite often I want to work with 'temporary' facts that I often refer
>> to as
>> 'indicator' facts.  With Jess I used to use ordered facts for this
>> purpose.
>> In Drools, do I have to create a Java bean for every such case?
>> What if I wanted to do the following,
>> then
>> assert("MapExists");
>> end
>> How would I match this fact elsewhere?
>> -Mitch
>>