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. :(
--
View this message in context:
http://www.nabble.com/Why-is-a-flat--object-recommended--tp15567690p24954...
Sent from the drools - user mailing list archive at
Nabble.com.