[rules-users] Best practice for 0..1 relations

[Vincent LEGENDRE]

In fact, you question is : What's the best way to define something that's needed in the RHS but is not matchable in the LHS?
You said "not important", but you want the income to be updated (I guess for other rules' LHS) ... so it was not clear.

And what about using an accumulate rather than a collect ? You won't use List anymore..
If you are reusing the same values again and again, have a look to queries.

If your problem is really restricted to a two-state one, then two rules can be ok, and especially if you think this is the natural way (it may be clearer this way so easier to maintain too).
But what if the list of relation's types grows? You add a 3rd rule? A 4th?
A big rule that accepts some Relations (based on a variable list of relation's types set in one unique place) and add their contribution to a sum using an accumulate seems more natural in this case.
It depends on how your are sure of your only two states ...




----- Mail original -----
De: "Christopher Dolan" <christopher.dolan at avid.com>
À: "Rules Users List" <rules-users at lists.jboss.org>
Envoyé: Lundi 23 Avril 2012 22:31:52
Objet: Re: [rules-users] Best practice for 0..1 relations

Sorry, I wasn't clear... In the example, it's the spouse that's the optional fact. I want the rule to fire whether or not a spouse exists, but the RHS computes the income differently if a spouse exists or not. If a spouse is added/removed, I want the rule to re-fire and the income should be changed.

Chris

-----Original Message-----
From: rules-users-bounces at lists.jboss.org [mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Welsh, Armand
Sent: Monday, April 23, 2012 3:22 PM
To: rules-users at lists.jboss.org
Subject: Re: [rules-users] Best practice for 0..1 relations

So, I assume the fact that is not needed in the LHS is Income.

By inserting Income into Working Memory, you are subjecting it to rete evaluation against the current knowledge tree.  I consider the cost of each operation.  Insert is very costly, and insertLogical even more costly.

I don't know anything about how your data model is built, but based on this very simple example, I would think you would be better off with a Global like this:

Global Income income

Style 1: one rule for each scenario
    rule "household income, single"
        when
            $p1 : Person()
            not Relation(person1 == $p1, type == "spouse")
        then
            income = new Income($p1.getIncome());
    end
    rule "household income, married"
        when
            $p1 : Person()
            Relation(person1 == $p1, type == "spouse", $p2: person2)
        then
            income = new Income($p1.getIncome() + $p2.getIncome());
    end

Style 2: a single rule with a collection
    rule "household income "
        when
            $p1 : Person()
            $rels : List() from collect(Relation($p1 == person1, type == "spouse"))
        then
            income = new Income($p1.getIncome() + ($rels.size() == 0 ? 0 : $rels.get(0).getPerson2().getIncome());
    end

Then in code, you can get the Global value to determine what it got set to, if you need outside of the Drools processing.  All thread safety factors must be considered in a multi-threaded environment.  Global are not objects know to rete, and therefore, use of them is very fast in the LHS.  And the RHS is never aware of changes to Globals (drools assumes them to be static values, that do not change) so care must be taken if using them in the RHS of rules, which I would advise against doing except for special cases where you know a change in the global variable won't be a problem (such as this simple scenario where the global is not used in the RHS at all).

-----Original Message-----
From: rules-users-bounces at lists.jboss.org [mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Christopher Dolan
Sent: Monday, April 23, 2012 1:01 PM
To: rules-users at lists.jboss.org
Subject: [rules-users] Best practice for 0..1 relations

What's the best way to encode a fact that's needed in the RHS but is not important in the LHS?

Consider a contrived example of computing total household income for single or married persons. I can think of two ways to encode this rule, but I don't like either of them:

Style 1: one rule for each scenario
    rule "household income, single"
        when
            $p1 : Person()
            not Relation(person1 == $p1, type == "spouse")
        then
            insertLogical(new Income($p1.getIncome()));
    end
    rule "household income, married"
        when
            $p1 : Person()
            Relation(person1 == $p1, type == "spouse", $p2: person2)
        then
            insertLogical(new Income($p1.getIncome() + $p2.getIncome()));
    end

Style 2: a single rule with a collection
    rule "household income "
        when
            $p1 : Person()
            $rels : List() from collect(Relation($p1 == person1, type == "spouse"))
        then
            insertLogical(new Income($p1.getIncome() + ($rels.size() == 0 ? 0 : $rels.get(0).getPerson2().getIncome()));
    end


(please ignore the bug that the income may get inserted twice because people are spouses of each other)


Style 1 is more verbose, but more straightforward: it's how I think of the problem intuitively. Style 2 is much more compact, and is more maintainable if I need to add more predicates or a more complicated RHS. But the idea of needing a List when I know there will be exactly 0 or 1 related facts just seems wrong.

I've searched for some LHS syntax that assigns a variable without participating in boolean evaluation, but I've failed to find anything.

Chris


_______________________________________________
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

_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users