Perhaps I should elaborate what I was hinting at with my joke ("Joneses").<br><br>A Java object (pojo) can be duplicated so that the new object will not<br>have the same identity (as tested by "=="). Its equals() method will return<div>
true if applied to this pair of pojos. This method may still return true after changing</div><div>certain properties, as it is generally customary to make the assumption that</div><div>some properties (primary key) uniquely identify the real world entity a pojo </div>
<div>represents. Also note that applications are usually based on a 1:1 relationship</div><div>between entities and pojos.</div><div><br>When we insert pojos as facts we have to contend with the notion that<br>facts represent truths. It does not make sense to insert a clone (i.e, another<br>
pojo instance with all properties being the same) of a fact - it can't be truer<br>than true. But it <i>might</i> make sense to insert another object relating to the<br>same real world entity, i.e., Entity.equals() returning true, but not <i>all</i> properties<br>
being equal, for instance two observations of the same thing, at different<div>times or by different observers.<br><br></div><div>In other words, an equals() that works well for testing the identity of entities</div><div>
represented by pojos is usually not the same as an equals() testing the</div><div>sameness of a fact. </div><div><br>-W<br><br>On 26/02/2012, Mark Proctor <<a href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>> wrote:<br>
> There are two types of facts - stated and justified. As explained in the<br>> TMS section.<br>><br>> Justified facts are ALWAYS equality based, as it's the nature of TMS.<br>> The other part of engine for stated facts is customizable and may work<br>
> in either equality mode or identity mode. Identity mode is default, as<br>> it's the most common way java developers expect to work, knowledge<br>> based engineers may prefer eqality mode.<br>><br>> We do discuss this in the maual. If it's clear, then please do help beef<br>
> up the docs on this. Fork the docs and submit a pull request, see:<br>> <a href="http://www.athico.com/Getting_Involved/gettinginvolved.html">http://www.athico.com/Getting_Involved/gettinginvolved.html</a><br>><br>
> Mark<br>> On 25/02/2012 19:41, SirMungus wrote:<br>>> By the way, while checking into various scenarios prompted by Wolfgang's<br>>> response, I came up with a very interesting test program:<br>>><br>
>> rule "Initialize"<br>>> salience 100<br>>> when<br>>> eval(true)<br>>> then<br>>> insert("one");<br>>> insert(new String("one"));<br>
>> insertLogical("two");<br>>> insertLogical(new String("two"));<br>>> end<br>>><br>>> rule "Find strings"<br>>> salience 50<br>>> when<br>
>> $s : String()<br>>> then<br>>> System.out.println("I found string: " + $s);<br>>> end<br>>><br>>> rule "Gather strings"<br>>> salience 50<br>
>> when<br>>> accumulate(<br>>> $s : String(),<br>>> $sSet : collectSet( $s ),<br>>> $sList : collectList( $s ) )<br>>> then<br>
>> System.out.println("Here is the set of all strings: " + $sSet);<br>>> System.out.println("Here is the list of all strings: " + $sList);<br>>> end<br>>><br>>> What would you expect that to output? How many "I found string: xxx" lines<br>
>> would there be? How many entries in the "set of all strings"? How many<br>>> entries in the "list of all strings"?<br>>><br>>> For my part, I figured there would be four "I found string: xxx" lines,<br>
>> two<br>>> entries in the set, and four entries in the list.<br>>><br>>> I was very surprised to find the following output:<br>>><br>>> I found string: two<br>>> I found string: one<br>
>> I found string: one<br>>> Here is the set of all strings: [two, one]<br>>> Here is the list of all strings: [one, one, two]<br>>><br>>> This strongly suggests that "insert" objects are held in an<br>
>> identity-preserving structure, but that "insertLogical" objects are held<br>>> in<br>>> an equals()-based structure.<br>>><br>>> I am glad for the identity-based handling of "insert" objects, especially<br>
>> considering that all of my inserted objects come from "outside" the<br>>> engine.<br>>> I would hate to see one of them fail to be considered by the rule engine.<br>>><br>>> I can almost see some usefulness for the equals() behavior of<br>
>> insertLogical<br>>> objects, but far more potential problems.<br>>><br>>> I think it's slightly dangerous that these behaviors differ and that it is<br>>> not, AFAIK, documented in a way that is clear to users of Drools.<br>
>><br>>> --<br>>> View this message in context:<br>>> <a href="http://drools.46999.n3.nabble.com/BUG-5-3-0-Final-CollectSetAccumulateFunction-should-probably-use-IdentityHashMap-internally-tp3774079p3775619.html">http://drools.46999.n3.nabble.com/BUG-5-3-0-Final-CollectSetAccumulateFunction-should-probably-use-IdentityHashMap-internally-tp3774079p3775619.html</a><br>
>> Sent from the Drools: Developer (committer) mailing list mailing list<br>>> archive at Nabble.com.<br>>> _______________________________________________<br>>> rules-dev mailing list<br>>> <a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>><br>> _______________________________________________<br>> rules-dev mailing list<br>
> <a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>><br></div></div>