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

If I have class Type { int field; setField( int f ){ field = f; } } and do modify( $type ){ setField( 42 ) } where is there a "nested accessor"?

-W On 23 June 2011 10:24, Mark Proctor <mproctor(a)codehaus.org <mailto:mproctor@codehaus.org>> wrote: On 23/06/2011 07:03, Wolfgang Laun wrote: > Eeek! > > Assume this: A is a field of B is a field of C is a field of D is > a... > > Object references remain the same, in all objects; I simply > modify A, and > "when you change [A] you are also changing [B], so I must notify the > engine for [B]" but that's a field of C... D... E... and so on, > until > 'I' for infinity?! > > _*/It's just a change in some fact object's hashCode that causes > this problem./*_ If you don't want any indexing in your rule engine. If you want indexing, you have to notify the engine. Changes to nested accessors have always been invisible to the engine. If a nested access changes, you must notify the engine of the root fact. Mark > > -W > > > > On 22 June 2011 22:37, Mark Proctor <mproctor(a)codehaus.org > <mailto:mproctor@codehaus.org>> wrote: > > As One is a field of Two. When you change One you are also > changing Two, so > > you most notify the engine for Two too. > > > > MArk > > On 22/06/2011 14:37, Wolfgang Laun wrote: > > > > To avoid misunderstandings: yes, equals() is written according > to hashCode, > > i.e., according to the usual Java conventions. > > > > If > > > > - an object of class Two contains a member of class One, and > > - one object Two and one object One are facts, and > > - a rule modifies One, changing its hashCode > > > > then > > > > another rule containing the patterns > > $one: One() > > $two: Two( $x: one == $one ) > > > > does NOT fire (any more). > > > > If you use the constraint > > one == $one || != $one > > the rule will fire, and you can observe that hashCode results > for $one and > > $x are the same and that $one.equals( $x ) returns true. > > > > Reproduced using 5.1.1 and 5.2.x > > > > -W > > > > > > > > > > _______________________________________________ > > rules-dev mailing list > > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > > _______________________________________________ > > rules-dev mailing list > > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev