[rules-users] Buggy query behavior in drools 5.6 and 6.1-SNAPSHOT ??

[Davide Sottara]

Esteban, I have created a ticket for this with
an explanation of the weird behavior.

https://issues.jboss.org/browse/DROOLS-414

The problem is in QueryElementBuilder line#343.
It's an easy fix but I don't have time for it right now,
could someone look into it?

Thanks
Davide


On 01/22/2014 06:00 PM, Esteban Aliverti wrote:
> Good catch Davide. I can confirm that not using nested accessors the
> query works as expected.
>
> Regards,
>
>
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> Esteban Aliverti
> - Blog @ http://ilesteban.wordpress.com
>
>
> On Wed, Jan 22, 2014 at 6:57 PM, Davide Sottara <dsotty at gmail.com
> <mailto:dsotty at gmail.com>> wrote:
>
>     Indeed, the use case can be simplified further:
>
>     package org.drools.test.bc;
>
>     declare Parent
>         attribute2 : String
>     end
>
>     declare Child
>         parentId : String
>     end
>
>     query getChildWithName( String $parentId, Child $child )
>         $child:= Child( parentId == $parentId )
>
>     end
>
>     rule "Insert Children"
>     when
>     then
>         Parent p1 = new Parent( "a1" );
>         Child c1p1 = new Child( "1" );
>
>         insert( c1p1 );
>         insert( p1 );
>
>     end
>
>     rule "Rule A"
>     when
>         $p: Parent( $a2 : attribute2 )
>         ?getChildWithName( $p.attribute2, $child;)
>     then
>         System.out.println("FOUND: "+ $child + " >> " +
>     $child.getParentId() + " == " + $p.getAttribute2() + " ??" );
>     end
>
>     It has nothing to do with nested objects, @PR or modifications.
>     It seems that the culprit is the chained property accessor.
>
>
>     Davide
>
>
>
>     On 01/22/2014 02:22 PM, Esteban Aliverti wrote:
>>     Hi guys,
>>     I was writing some rules using backward chaining and found a
>>     strange behavior. 
>>     I managed to isolate the error in the test project I'm attaching. 
>>
>>     In the project I have 2 classes: Parent and Child
>>
>>     Parent:
>>         * String id
>>         * String attribute1
>>         * String attribute2
>>         * List<Child> children
>>
>>     Child:
>>         * String parentId;
>>         * String name;
>>         * String value;
>>
>>
>>     In the test I'm creating 1 Parent object with just 1 child and
>>     then inserting the Parent object into a drools session:
>>
>>             Parent p1 = new Parent();
>>             p1.setId("1");
>>             p1.setAttribute1("a1");
>>             p1.setAttribute2(null);
>>             
>>             Child c1p1 = new Child();
>>             c1p1.setName("n1");
>>             c1p1.setParentId(p1.getId());
>>             c1p1.setValue("v1.1");
>>             p1.addChild(c1p1);
>>             
>>             kSession.insert(p1);
>>             kSession.fireAllRules();
>>
>>
>>     So far so good. 
>>     The rules I have in my session are the following:
>>
>>     declare Parent
>>         @propertyReactive
>>     end
>>
>>     query getChildWithName(String $parentId, String $name, Child $child)
>>         $child:= Child(parentId == $parentId, name == $name)
>>     end
>>
>>     rule "Insert Children"
>>     when
>>         $p: Parent()    @watch(!*)
>>         $c: Child() from $p.children
>>     then
>>         System.out.println("Inserting child "+$c);
>>         insert($c);
>>     end
>>
>>     rule "Rule A"
>>     when
>>         $p: Parent(attribute2 != null)
>>         ?getChildWithName($p.attribute2, "n1", $child;)
>>     then
>>         System.out.println("FOUND: "+$child+". The attribute
>>     'parentId' of this object must have the value
>>     '"+$p.getAttribute2()+"'. Does it? "+$child.getParentId()+" ==
>>     "+$p.getAttribute2()+" ??");
>>         globalList.add($child);
>>     end
>>
>>
>>     rule "Copy Attribute1 into Attribute2"
>>     when
>>         $p: Parent(attribute1 != null, attribute2 == null)
>>     then
>>         modify($p){
>>             setAttribute2($p.getAttribute1())
>>         }
>>     end
>>
>>     The important part here is 'Rule A' and 'Copy Attribute1 into
>>     Attribute2'. The latter copies the value of attribute1 to
>>     attribute2 for any Parent object present in the session. (Note
>>     that the parent I'm inserting has attribute2 = null). 'Rule A' is
>>     then using a query to get a Child object that has a parent with
>>     id = $p.attribute2 (where $p is a previously matched Parent).
>>     Given that I only have 1 Parent in my session and that its id is
>>     '1' I don't expect 'Rule A' to be activated/executed. When I
>>     modify parent.attribute2 in 'Copy Attribute1 into Attribute2' I'm
>>     setting its value to 'a1'. 'Rule A' (via the query) should then
>>     look for a Child with parentid = 'a1' and It shouldn't find
>>     anything. 
>>     Funny thing is that 'Rule A' activates and fires. The child
>>     object that is 'returned' by the query has a parentId of '1' so I
>>     don't know how this behavior is possible. If you take a look at
>>     the System.out output you will see that the activation makes no
>>     sense at all.
>>
>>     Am I doing something wrong in my project? Is this a bug? Is this
>>     the expected behavior?
>>
>>     Regards,
>>
>>
>>
>>     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>>
>>     Esteban Aliverti
>>     - Blog @ http://ilesteban.wordpress.com
>>
>>
>>     _______________________________________________
>>     rules-users mailing list
>>     rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>     _______________________________________________
>     rules-users mailing list
>     rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140122/722767b5/attachment.html