-----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users- bounces(a)lists.jboss.org] On Behalf Of Evert Penninckx Sent: 18 June 2010 08:13 To: rules-users(a)lists.jboss.org Subject: [rules-users] Accessing collections in conditional statements (inside/outside working memory) Hi I'm having trouble understanding how collections are accessed in conditions and what this means in terms of perfomance. My app has concepts with a unidirectional composite relation. Making it bidirectional, as suggested in other posts, is really not preferred. This is the most natural model for this business. declare Parent children : Collection // Collection<Child> end declare Child anAttribute : String end With this set-up, I can think of only two rules to check for the existence of a child and only one to check for the absence (without starting to check for the size of a populated list, which seems farfetched and unreadable): rule "01 - Parent has child - using contains" when $child : Child( ) Parent( children contains $child ) then // do stuff end rule "02 - Parent has child - using from" when $parent : Parent( ) Child( ) from $parent.children then // do stuff end rule "03 - Parent does not have child - using from" when $parent : Parent( ) not Child( ) from $parent.children then // do stuff end 1) Is the cost of the "contains" in rule 01 the same as the "from" in rule 02? Why (not)? If so, inserting the Child facts in the working memory seems not necessary. 2) I read in other posts and the user guide that putting all facts in working memory should be faster. Is it correct to say, that the perfomance gain will only be achieved when not using the "from" CE and thus only by using a bi-directional relation between Parent and Child? In any case, it seems to me that stuffing child objects into working memory shouldn't be the concern of a client calling a "rule service". So should this be more optimal, I'd make the rules insert the facts using an agenda/ruleflow to make sure everything is inserted before doing the business stuff. Greetz -Evert --- If you are posting a question, please try search first. Your question may have already been answered. Don't post repeatedly. Wait for a few days. People will read your post by email. -- View this message in context: http://drools-java-rules- engine.46999.n3.nabble.com/Accessing-collections-in-conditional-statements- inside-outside-working-memory-tp905005p905005.html Sent from the Drools - User mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Thanks for the info, Thomas. Currently, I'm not modifying the children. Yet :) For now my rules are only deriving, I hope I can keep it this way, but we'll see. Good point about the exists. Many of my rules have indeed as condition the existence of "a" child. But, in many cases I use some bindings which are referred to in another condition or consequence, like rule "01" when $child : Child($attribute : attribute) $parent : Parent(children contains $child) then // do stuff end To use the exists clause I rewrote them to rule "02" when $parent : Parent() exists( Child() from $parent.children ) then // do stuff end However, in rule 02 I loose the binding for $attribute. I'll have to get it from another, probably more adequate, fact. Greetz Evert -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Accessing-collections... Sent from the Drools - User mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Edson Tirelli-3 wrote: > > Also, remember you can negate operators: > Parent( collection contains $child ) > Parent( collection not contains $child ) > That is more efficient than composing "exists"/"not" and "from". > True, but "children not contains $child" expects to have the Child bound in a previous condition, implying (to my understanding) that "a" child must be present to match the condition, while this might not and, in my rule, mustn't be the case at all.