On 23 June 2011 11:28, Mark Proctor <mproc...@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 > >
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
