<br><br><div class="gmail_quote">On 23 June 2011 11:28, Mark Proctor <span dir="ltr"><<a href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<u></u>
<div text="#000000" bgcolor="#ffffff"><div class="im">
On 23/06/2011 10:19, Wolfgang Laun wrote:
<blockquote type="cite">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 <i><b>must
not refer to mutable fields</b></i> of that object.<br>
</blockquote>
hashCode method <i><b>must not refer to mutable fields</b></i> of
that object.<br></div>
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.<br></div></blockquote><div><br>(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?)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div text="#000000" bgcolor="#ffffff">
<br>
I don't really know what more to say than...<br>
Nested accessors are "black box" if you modify a nested accessor you
must notify the root object(s) that are inserted into the engine.<br>
<br>
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.<br></div></blockquote><div><br>So the warning must be written saying something like what I try to compose below.<br><br><warning><br><ul><li>There is a fact type A with a field b of class B and</li>
<li>patterns for A use constraints comparing b with "==" to some other object of type B and<br></li><li>B overrides hashCode using a field c of B and</li><li>this field is changed in an update of some object B.</li>
</ul>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.<br><br>In most real-world situation, this may not be possible. Then, <br>
<ul><li>either avoid constraining on object references by replacing this with primary key field constraints,</li><li>or refrain from using c in hashCode.</li></ul></warning><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff">
<br>
This is why other engines don't support Objects as fields, you can
only use values - strings, numbers etc. </div></blockquote><div><br>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.<br>
<br>-W<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div text="#000000" bgcolor="#ffffff">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.<br><font color="#888888">
<br>
Mark</font><div><div></div><br></div></div></blockquote></div><br>