Java pojo's nested fields is just a weak way to represent relations between objects. If you want to exploit those properly in a rule engine, best to use real relations.

Libor Nenadál wrote:
Mark Proctor wrote:
We can exploit cartesian products and indexing for == constraints. If 
its a nested model we have to iterate over all possible instances. The 
other problem is if the nested model changes the engine has no idea this 
has happened, which if you are not careful can lead to data integrity 

I think that plain flat model is too limited for real life. In fact in most
situations you just cannot avoid nesting.
For example when I try to search for cars with 4 cylinder engine the best
approach I found is:

rule "get 4 cylinder cars"
    Car ( $e: engine != null ) // car without engine? where are we? :)
    Engine ( cylinderCount == 4 ) from $e
    System.out.println("Found 4 cylinder car.");

This should be quite effective. I doubt that the following solution with
cartesian product has the same complexity:

rule "get 4 cylinder cars"
    $e: Engine ( cylinderCount == 4 )
    Car ( engine == $e )
    System.out.println("Found 4 cylinder car.");

Using approach Car ( engine.cylinderCount == 4 ) tends to raise
NullPointerException and I had problems with assigning the cylinderCount to
variable so this was not a way to go for me.

But this is not much a problem for me as I am a programmer and I can
understand the rule language and data structures. But when business users
are to edit rules (using Guvnor as the tool of choice) we come to troubles.
I think that guided editor for rules does not allow "from". More importantly
- can you create such a structure for a test scenario? I failed. :(