Due to popular demand, we are glad to say that we just committed to the trunk (available in 4.0MR3) the changes to allow nested accessors, special syntax for map and array access, as well as complex expression evaluations. In other words, users can now write constraints like:
rule "Complex expressions"
$country : Contry( name == "Brazil" )
Person( address['business'].phone.contryCode == $country.phone.countryCode )
// do something
On the above rule, 'address' is a map of objects, where the key 'business' is associated with an Address POJO, that contains an array of Phone POJOs, where we are accessing the CountryCode attribute of the first object in the array.
Does that mean that users are not required to worry about modeling flatter object models anymore?
Definitively, it is not the case. We continue to say that in order to use the full rules engine's power, the users must use a relational object model. Although, we provide the above described functionality to allow for good alternatives for the case where a relational model does not fit well with the whole application design.
It is important to understand that expressions like the above are translated into inline-evals()**, an so they must be constant over time to avoid unpredictable behavior. Also, it is important to note that it is not viable to shadow entire object graphs, and again, this requires the constrained attributes to be constant while the fact is in the working memory.
** NOTE: in 4.0, we are doing a nomenclature change. What we used to call a predicate in version 3.0.x will from now on be called "inline-eval". The reason for the change is we will soon support another constructions that are known as predicates.
Drools Dev Team
[EDIT: added the note about the difference between predicate and inline-eval nomenclature change]