[jboss-jira] [JBoss JIRA] Updated: (JBRULES-1511) Can only reason over sub-objects if you use the From Conditional Element

[Edson Tirelli (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBRULES-1511?page=all ]

Edson Tirelli updated JBRULES-1511:
-----------------------------------

    Fix Version/s: 5.0.0-M1

This is a known limitation In 4.0.x, all predicates must be time constant, and any expression using nested accessors are converted into predicates. From the documentation:

==========
6.5.2.1.3. Nested Accessors

Drools does allow for nested accessors in in the field constraints using the MVEL accessor graph notation. Field constraints involving nested accessors are actually re-written as an MVEL dialect inline-eval. Care should be taken when using nested accessors as the Working Memory is not aware of any of the nested values, and do not know when they change; they should be considered immutable while any of their parent references are inserted into the Working Memory. If you wish to modify a nested value you should remove he parent objects first and re-assert afterwards. If you only have a single parent at the root of the graph, when in the MVEL dialect, you can use the 'modify' keyword and its block setters to write the nested accessor assignments while retracting and inserting the the root parent object as required. Nested accessors can be used either side of the operator symbol.
==============

So, to avoid this and related problems, you can either ensure your predicates and expressions using nested accessors are immutable, or use the modify block instead of the update keyword. 
In your example, that means changing your first rule to:

rule "30 is the new 20"
when
	person : Person( $d : details, $a : details.age == 30 )
then
	System.out.println( "Now 20 : " + person );
	modify( person ) {
	    getDetails().setAge( 20 )
	}
end

More details: http://blog.athico.com/2007/12/modify-block-for-java-dialect.html

Having said that, this problem is fixed in 5.0 with the new matching algorithm, but there is nothing more we can do about it in 4.0.x. 

[]s
Edson

> Can only reason over sub-objects if you use the From Conditional Element
> ------------------------------------------------------------------------
>
>                 Key: JBRULES-1511
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1511
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions: 4.0.4, 4.0.5
>            Reporter: Aaron Dixon
>         Assigned To: Edson Tirelli
>             Fix For: 5.0.0-M1
>
>         Attachments: drools-issue.zip
>
>
> It appears that you MUST use the From Condition Element to reason over sub-objects or else Drools yields unpredictable behavior.
> The first two rules below appear to be semantically equivalent. However the "bad" rule (the rule that does not use the from conditional element) does not get activated correctly when there is another rule (see the third rule) that modifies the age sub-property before the first two rules are activated:
> rule "Older than 20 - Good"
> salience -100
> when
> 	person : Person( )
> 	Details( age > 20 ) from person.details
> then
> 	System.out.println( "Older than 20 (good) : " + person );
> end
> rule "Older than 20 - Bad"
> salience -100
> when
> 	person : Person( details.age > 20 )
> then
> 	System.out.println( "Older than 20 (bad) : " + person );
> end
> rule "30 is the new 20"
> when
> 	person : Person( details.age == 30 )
> then
> 	person.getDetails().setAge( 20 );
> 	System.out.println( "Now 20 : " + person );
> 	update( person );
> end
> Given that the "bad" rule is semantically equivalent to the second rule, Drools should treat both rules the same in the engine. See the referenced forum thread for further justification for this claim.
> Also, see the attached zip for an executable example.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira