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

[Mark Proctor]

On 23/06/2011 09:32, Wolfgang Laun wrote:
> If I have
>    class Type {
>       int field;
>       setField( int f ){ field = f; }
>    }
>
> and do
>
>    modify( $type ){ setField( 42 ) }
>
> where is there a "nested accessor"?
$one: One()
$two: Two( $x: one == $one )

If you change a field on object "one". that field is a nested accessor 
to Two.
one.field1 = "x"
is the same as doing
two.one.field1 = "x"

so to "two" changing the field of 1 is a nested accessor.

Think about how indexing works.
left == right

when two objects are == each other indexing creates a bucket for the 
left and a bucket for the right. If you change the hashcode of the one 
on the right, how will it find the bucket on the left?

Mark

>
> -W
>
> On 23 June 2011 10:24, Mark Proctor <mproctor at codehaus.org 
> <mailto:mproctor at 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 at codehaus.org
>>     <mailto:mproctor at 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 at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>     > https://lists.jboss.org/mailman/listinfo/rules-dev
>>     >
>>     >
>>     > _______________________________________________
>>     > rules-dev mailing list
>>     > rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>     > https://lists.jboss.org/mailman/listinfo/rules-dev
>>     >
>>     >
>>
>>
>>     _______________________________________________
>>     rules-dev mailing list
>>     rules-dev at lists.jboss.org  <mailto:rules-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>     _______________________________________________
>     rules-dev mailing list
>     rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110623/40ce9d95/attachment-0001.html