[rules-dev] Changing a fact's hashCode causes rules not to fire

[Wolfgang Laun]

On 23 June 2011 11:28, Mark Proctor <mproctor at codehaus.org> wrote:

> **
> On 23/06/2011 10:19, Wolfgang Laun wrote:
>
> Well, you are saying that if you are using references to fact objects in
> combination with constraints comparing such a reference to some other object
> any (overridden) hashCode method *must not refer to mutable fields* of
> that object.
>
> hashCode method *must not refer to mutable fields* of that object.
> That's not a good idea really. Hashcode's should refer to fields that you
> constrain on, as a general good rule. and those fields are normally mutable.
>

(Aside: Which may mean that all attributes of, say, an article - price,
storage quantity,... - should be part of the hash code, since those sure are
used in constraints?)


> I don't really know what more to say than...
> Nested accessors are "black box" if you modify a nested accessor you must
> notify the root object(s) that are inserted into the engine.
>
> If you want to write up some paragraphs talking people through how
> hashcode's and hashmap's work. Specifiically if you change the hashcode of
> an object that is in map you won't be able to find it in the map any more -
> which is what is happening to you. Notification effectively takes the root
> object out and put's it back in again, so it lives in the correct index.
>

So the warning must be written saying something like what I try to compose
below.

<warning>

   - 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.

</warning>


>
> This is why other engines don't support Objects as fields, you can only use
> values - strings, numbers etc.
>

Jess supports type OBJECT in a deftemplate without shadow facts, but then a
deftemplate does not override hashCode, and so the problem does not arise in
the first place.

-W


> For them it's worse though, they have to use techniques like shadow facts
> otherwise they get memory corruption - but shadow facts only work on direct
> values, and cannot shadow objects and nested fields. If you tried to do this
> stuff in other engines they would just get corrupted. It's only because we
> do a tree-graph based rete network for assymetrical retract that we can
> allow you to do this without corruption, but you must still notify the
> engine.
>
> Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110623/220ad43d/attachment.html