[rules-users] Why Using "from" Always Return A New Fact?

Edson Tirelli ed.tirelli at gmail.com
Thu Jan 20 11:57:52 EST 2011


   Yes, but just to clarify: as it is now, we parse semantic blocks of code
like RHS as a black box (chunk if you will) and then re-parse that with the
appropriate dialect parser (like java). Same for expressions in the rule,
that we chunk and delegate to MVEL. That is why, for instance, to write an
expression in a pattern in need the ugly ( ):

Person( age == ( $someAge + 1 ) )

   That also screws with our error handling capabilities. Example: as of
today, in the eclipse editor, if you have a parsing error in the
consequence, we show the error in the rule header instead of the proper line
in the consequence.

   The changes we are doing in the parser now means that we will be able to
parse 100% of the content of the DRL file (no black boxes/chunking anymore)
and with that improve error handling, code completion, improve syntax and
allow us to do smarter static code analysis. Example of the results as of
this morning:

@name4( k1 = "a",
formula = Math.max( 10 + 25, 22 ) % 2 + someVariable,
array = { a, b, c } )

   Above example is for annotations, but the same will happen everywhere,
including the LHS. See how "formula" uses a free form expression without any
kind of clutter/delimiters/etc?

   Edson


2011/1/20 Greg Barton <greg_barton at yahoo.com>

> When you say "owning 100% of the language syntax" does that include the
> RHS?  Just curious.
>
> GreG
>
> On Jan 19, 2011, at 22:04, Edson Tirelli <ed.tirelli at gmail.com> wrote:
>
> >   As of Drools 5.1.1, drools looks at the expression in "from" as a
> > black box. Every time it is executed, drools creates a new fact handle
> > to wrap the result(s). Since the lock and no-loop features are based
> > on the fact handles, the sometimes undesired interaction occurs. We
> > may be able to improve this in drools 6, when we will have the engine
> > owning 100% of the language syntax, that will enable us to run better
> > expression analisys than we can do today.
> >
> >   Edson
> >
> > Em quarta-feira, 19 de janeiro de 2011,
> > hyjshanghai<hyjshanghai at gmail.com> escreveu:
> >>
> >> You explanation is very reasonable:
> >> the engine assumes anything within $p may be changed by modify($p),
> although
> >> $p.address is not changed actually.
> >>
> >> However, I tried these rules myself and both rules were fired. Why?
> >> According to the document, only one of the rules should fire; the
> other's
> >> activation should be cancelled because the engine assumes $p has
> changed,
> >> which may mismatch the other rule, right?.
> >>
> >> The following are the output and my rules. The only difference between
> my
> >> rules and the document's is that my rules don't belong to any
> >> ruleflow-group.
> >>
> >> ==== Program Output of Inserting a "new Person()" and Firing All Rules.
> >> BEGIN====
> >> Rule 'Apply discount' fired. Person: Person{name[Tom],
> >> address[Address{state[NC], city[Raleigh]}], region[null], discount[0.9]}
> >> Rule 'Assign to sales region 1' fired. Person: Person{name[Tom],
> >> address[Address{state[NC], city[Raleigh]}], region[sales region 1],
> >> discount[0.9]}
> >> ==== Program Output of Inserting a "new Person()" and Firing All Rules.
> >> END====
> >>
> >> ==== The Rules I Tested. BEGIN ====
> >> package hello.rules
> >> import java.util.*
> >> import java.math.*
> >> import hello.model.Address;
> >> import hello.model.Person;
> >>
> >> rule "Assign to sales region 1"
> >> lock-on-active true
> >> when
> >>    $p : Person()
> >>    $a : Address( state=="NC") from $p.address
> >> then
> >>    modify ($p) { setRegion("sales region 1") }
> >>    System.out.println("Rule 'Assign to sales region 1' fired. Person:
> >> "+$p);
> >> end
> >>
> >> rule "Apply discount"
> >> lock-on-active true
> >> when
> >>    $p : Person()
> >>    $a : Address( city=="Raleigh") from $p.address
> >> then
> >>    modify ($p) { setDiscount((float)0.9) }
> >>    System.out.println("Rule 'Apply discount' fired. Person: "+$p);
> >> end
> >> ==== The Rules I Tested. END ====
> >>
> >> ==== The Person and Address. BEGIN ====
> >> public class Person
> >> {
> >>    private String name;
> >>    private Address address;
> >>    private String region;
> >>    private float discount;
> >>    public String getRegion() {
> >>        return region;
> >>    }
> >>    public void setRegion(String region) {
> >>        this.region = region;
> >>    }
> >>    public float getDiscount() {
> >>        return discount;
> >>    }
> >>    public void setDiscount(float discount) {
> >>        this.discount = discount;
> >>    }
> >>
> >>    public String getName() {
> >>        return name;
> >>    }
> >>    public void setName(String name) {
> >>        this.name = name;
> >>    }
> >>    public Address getAddress() {
> >>        return address;
> >>    }
> >>    public void setAddress(Address address) {
> >>        this.address = address;
> >>    }
> >>    @Override
> >>    public String toString()
> >>    {
> >>        return String.format("Person{name[%s], address[%s], region[%s],
> >> discount[%s]}",
> >>                name, address.toString(), region, discount);
> >>    }
> >> }
> >>
> >> public class Address
> >> {
> >>    private String state;
> >>    private String city;
> >>    public String getState() {
> >>        return state;
> >>    }
> >>    public void setState(String state) {
> >>        this.state = state;
> >>    }
> >>    public String getCity() {
> >>        return city;
> >>    }
> >>    public void setCity(String city) {
> >>        this.city = city;
> >>    }
> >>
> >>    @Override
> >>    public String toString()
> >>    {
> >>        return String.format("Address{state[%s], city[%s]}", state,
> city);
> >>    }
> >> }
> >> ==== The Person and Address END ====
> >> --
> >> View this message in context:
> http://drools-java-rules-engine.46999.n3.nabble.com/Why-Using-from-Always-Return-A-New-Fact-tp2286393p2292029.html
> >> Sent from the Drools - User mailing list archive at Nabble.com.
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >
> > --
> >  Edson Tirelli
> >  JBoss Drools Core Development
> >  JBoss by Red Hat @ www.jboss.com
> >
> > _______________________________________________
> > rules-users mailing list
> > 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
>



-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110120/fff4127d/attachment.html 


More information about the rules-users mailing list