Re: [rules-users] Unexpected behavior of accumulate() and insertLogical() when the result() goes from matching a constraint to not matching

I agree that it is bad form to introduce unnecessary nulls. I mostly did that for the sake of simplicity in the example. I tried out your initial proposal of how to implement this, where you put the logic previously in my `result` segment of the `accumulate` into the "result pattern" segment of the rule instead. This seems to have the effect that I am going for, but I'm a little suprised that it produces different results. The reason I say this, is here: $sample : SampleFact() from accumulate( $sf : SampleFact(), init( SampleFact temp = null; ), action( temp = ((null == temp) || ($sf.version > temp.version)) ? $sf : temp; ), result( ((null != temp) && (temp.value < 10)) ? temp : null; )) When a SampleFact is matched in the accumulate that has the highest version, but does not have a value < 10, the `result` should produce the value null, which I'd not expect to match the "result pattern" of SampleFact(). So basically, I would have expected this to have the same effect as putting the restricitons in the result pattern segment itself, as your example showed me (i.e. SampleFact( value < 10 ) ). Going with Davide's previous reply; the difference seems to be that if the `result` produces null, then it does not match SampleFact(), and so *does not* override previous accumulate activations that did match. However, when `result` produces a SampleFact that does not match SampleFact( value < 10), it *does* override previous activations from the accumulate. So I feel that there is a gap in my understanding of what is happening here at this point. I appreciate all the helpful feedback on this topic! -- View this message in context: http://drools.46999.n3.nabble.com/Unexpected-behavior-of-accumulate-and-i... Sent from the Drools: User forum mailing list archive at Nabble.com.