Re: [rules-dev] Changing a fact's hashCode causes rules not to fire
On 23 June 2011 11:28, Mark Proctor <mproctor(a)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
Attachments:
- attachment.html (text/html — 4.1 KB)