Re: [rules-users] Why is a flat object recommended?
I would hesitate using from for accessing nested structures for performance reasons. See the attached project: $ java -jar target/DroolsNestedTest-1.0.jar from.drl Time: 980ms BAR Duplicates: 58 FOO Duplicates: 38 $ java -jar target/DroolsNestedTest-1.0.jar reference.drl Time: 36ms BAR Duplicates: 48 FOO Duplicates: 38 Note the 27x performance difference. :) In this case it's because I used two from statements in a rule, but this is a pretty common occurrence. Just try upping the COUNT parameter in DroolsTest. Prepare to wait a while for the from.drl to finish. The reference.drl does just fine. So, to help out your business users, you might dry a domain specific language. You can generate the nested reference == just as easily as a from expression. --- On Thu, 8/13/09, Libor Nenadál libor.nena...@gmail.com wrote: From: Libor Nenadál libor.nena...@gmail.com Subject: Re: [rules-users] Why is a flat object recommended? To: rules-users@lists.jboss.org Date: Thursday, August 13, 2009, 9:56 AM 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--tp15567690p24954944.html Sent from the drools - user mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users DroolsNested.tar.gz Description: GNU Zip compressed data ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Why is a flat object recommended?
Mark thank you for your reply! What you are saying is that the example Car ( engine.cylinderCount == 4 ) is wrong and correct is: $e: Engine ( cylinderCount == 4 ) Car ( engine == $e ) which is representation of real relations? I thought about the example I wrote here overnight and I realized that the solution without 'from' in fact can be optimal as it can easily eliminate non-matching facts without going through the object structure. Cheers, Libor Mark Proctor wrote: 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. :( ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- View this message in context: http://www.nabble.com/Why-is-a-flat--object-recommended--tp15567690p24967167.html Sent from the drools - user mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Why is a flat object recommended?
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--tp15567690p24954944.html Sent from the drools - user mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Why is a flat object recommended?
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. :( ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Why is a flat object recommended?
Christie, Blair wrote: In the documents this is dicussed briefly: ). Object models can often have complex relationships and hierarchies in them - for rules you will want to simplify and flatten the model where possible, and let the rule engine infer relationships (as it provides future flexibility. What does it mean that the rule engine can infer relationships? Are there performance reasons for having a flat model? 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. Cheers, Blair ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
