This is the state of things in connection with hashCode, update and object
comparison:
- There is a fact type A with a field b of class B and
- patterns for A use constraints comparing b with "==" to some other
object of type B and
- B overrides hashCode using a field c of B and
- this field is changed in an update of some object B.
In any situation like this, it is necessary to instruct the engine that any
fact of type A containing a reference to the changed fact B has changed.
In most real-world situation, this may not be possible. Then,
- either avoid constraining on object references by replacing this with
primary key field constraints,
- or refrain from using c in hashCode.
-W
On 22 June 2011 13:58, M. H. <hugues_81(a)hotmail.com> wrote:
And yet the funny thing is it does affect the other fact:
if you run this without the hashCode and equals method, it works fine, but
if you run it with hashCode and equals overriden, the second rule won't be
executed.
You mentionned before the usual rules for hashCode and equals, what are
they
appart from equals=>equal hashCodes? I don't understand why this works in a
case and not in the other, so maybe I'm missing something here?
Thanks,
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-Drools-use-of-hashCode-tp30...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users