[rules-users] Why is a flat object recommended?

[Mark Proctor]

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.

Mark
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 
>> issues.
>>
>>     
> 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"
>   when
>     Car ( $e: engine != null ) // car without engine? where are we? :)
>     Engine ( cylinderCount == 4 ) from $e
>   then
>     System.out.println("Found 4 cylinder car.");
> end
>
> This should be quite effective. I doubt that the following solution with
> cartesian product has the same complexity:
>
> rule "get 4 cylinder cars"
>   when
>     $e: Engine ( cylinderCount == 4 )
>     Car ( engine == $e )
>   then
>     System.out.println("Found 4 cylinder car.");
> end
>
> 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. :(
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090813/8110d714/attachment.html