On 23 June 2011 11:28, Mark Proctor <mproctor@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