When we insert pojos as facts we have to contend with the notion that
facts represent truths. It does not make sense to insert a clone (i.e, another
pojo instance with all properties being the same) of a fact - it can't be truer
than true. But it might make sense to insert another object relating to the
same real world entity, i.e., Entity.equals() returning true, but not all properties
being equal, for instance two observations of the same thing, at different

times or by different observers.

In other words, an equals() that works well for testing the identity of entities

represented by pojos is usually not the same as an equals() testing the

sameness of a fact.

-W

On 26/02/2012, Mark Proctor <mproctor@codehaus.org> wrote:
> There are two types of facts - stated and justified. As explained in the
> TMS section.
>
> Justified facts are ALWAYS equality based, as it's the nature of TMS.
> The other part of engine for stated facts is customizable and may work
> in either equality mode or identity mode. Identity mode is default, as
> it's the most common way java developers expect to work, knowledge
> based engineers may prefer eqality mode.
>
> We do discuss this in the maual. If it's clear, then please do help beef
> up the docs on this. Fork the docs and submit a pull request, see:
> http://www.athico.com/Getting_Involved/gettinginvolved.html
>
> Mark
> On 25/02/2012 19:41, SirMungus wrote:
>> By the way, while checking into various scenarios prompted by Wolfgang's
>> response, I came up with a very interesting test program:
>>
>> rule "Initialize"
>> salience 100
>> when
>> eval(true)
>> then
>> insert("one");
>> insert(new String("one"));
>> insertLogical("two");
>> insertLogical(new String("two"));
>> end
>>
>> rule "Find strings"
>> salience 50
>> when
>> $s : String()
>> then
>> System.out.println("I found string: " + $s);
>> end
>>
>> rule "Gather strings"
>> salience 50
>> when
>> accumulate(
>> $s : String(),
>> $sSet : collectSet( $s ),
>> $sList : collectList( $s ) )
>> then
>> System.out.println("Here is the set of all strings: " + $sSet);
>> System.out.println("Here is the list of all strings: " + $sList);
>> end
>>
>> What would you expect that to output? How many "I found string: xxx" lines
>> would there be? How many entries in the "set of all strings"? How many
>> entries in the "list of all strings"?
>>
>> For my part, I figured there would be four "I found string: xxx" lines,
>> two
>> entries in the set, and four entries in the list.
>>
>> I was very surprised to find the following output:
>>
>> I found string: two
>> I found string: one
>> I found string: one
>> Here is the set of all strings: [two, one]
>> Here is the list of all strings: [one, one, two]
>>
>> This strongly suggests that "insert" objects are held in an
>> identity-preserving structure, but that "insertLogical" objects are held
>> in
>> an equals()-based structure.
>>
>> I am glad for the identity-based handling of "insert" objects, especially
>> considering that all of my inserted objects come from "outside" the
>> engine.
>> I would hate to see one of them fail to be considered by the rule engine.
>>
>> I can almost see some usefulness for the equals() behavior of
>> insertLogical
>> objects, but far more potential problems.
>>
>> I think it's slightly dangerous that these behaviors differ and that it is
>> not, AFAIK, documented in a way that is clear to users of Drools.
>>
>> --
>> View this message in context:
>> http://drools.46999.n3.nabble.com/BUG-5-3-0-Final-CollectSetAccumulateFunction-should-probably-use-IdentityHashMap-internally-tp3774079p3775619.html
>> Sent from the Drools: Developer (committer) mailing list mailing list
>> archive at Nabble.com.
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>