11:44 a.m.
Perhaps I should elaborate what I was hinting at with my joke ("Joneses").
A Java object (pojo) can be duplicated so that the new object will not
have the same identity (as tested by "=="). Its equals() method will return
true if applied to this pair of pojos. This method may still return true
after changing
certain properties, as it is generally customary to make the assumption that
some properties (primary key) uniquely identify the real world entity a
pojo
represents. Also note that applications are usually based on a 1:1
relationship
between entities and pojos.
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(a)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-CollectSetAccumulateFun...
> Sent from the Drools: Developer (committer) mailing list mailing
list
> archive at Nabble.com.
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev