2:23 p.m.
Can someone explain to me why these two rules behave differently? I expected
that the second rule would produce the same output as the first but it seems
to ignore the first half of the logical or expression. Is this because the
unification happens before the null checks occur?
declare Foo
name : String
item : Item
end
declare Item
id : long
end
rule "insert stuff"
when
then
Item item1 = new Item(1);
Foo foo1 = new Foo("foo1", item1);
insert(foo1);
Foo foo3 = new Foo("foo3", null);
insert(foo3);
end
rule "Unification Test Rule"
when
f : Foo ( item != null, $item := item )
f2 : (
Foo ( item == null )
or Foo ( $item := item )
)
then
System.out.println(String.format("%s Fired:\n\tFoo: %s\n\t%s",
kcontext.getRule().getName(), f, f2));
end
rule "Unification Test Rule 2"
salience -10
when
f : Foo ( item != null, $item := item )
f2 : Foo ( ( item == null ) || ( item != null && $item := item ) )
then
System.out.println(String.format("%s Fired:\n\tFoo: %s\n\t%s",
kcontext.getRule().getName(), f, f2));
end
Unification Test Rule Fired:
Foo: Foo( name=foo1, item=Item( id=1 ) )
Foo( name=foo3, item=null )
Unification Test Rule Fired:
Foo: Foo( name=foo1, item=Item( id=1 ) )
Foo( name=foo1, item=Item( id=1 ) )
Unification Test Rule 2 Fired:
Foo: Foo( name=foo1, item=Item( id=1 ) )
Foo( name=foo1, item=Item( id=1 ) )
--
View this message in context:
http://drools.46999.n3.nabble.com/Unification-with-logical-or-question-tp...
Sent from the Drools: User forum mailing list archive at Nabble.com.
12:35 a.m.
On 08/06/2012, bdolbeare <bdolbeare(a)yahoo.com> wrote:
Can someone explain to me why these two rules behave differently? I
expected
that the second rule would produce the same output as the first but it
seems
to ignore the first half of the logical or expression. Is this because the
unification happens before the null checks occur?
It's a simple case of the "sorprise" ( sic ;-) ).
A rule containing the Conditional Element "or" is transformed into two
(or more, depending on the number of operands) rules running under the
same name. See the Expert manual.
-W
declare Foo
name : String
item : Item
end
declare Item
id : long
end
rule "insert stuff"
when
then
Item item1 = new Item(1);
Foo foo1 = new Foo("foo1", item1);
insert(foo1);
Foo foo3 = new Foo("foo3", null);
insert(foo3);
end
rule "Unification Test Rule"
when
f : Foo ( item != null, $item := item )
f2 : (
Foo ( item == null )
or Foo ( $item := item )
)
then
System.out.println(String.format("%s Fired:\n\tFoo: %s\n\t%s",
kcontext.getRule().getName(), f, f2));
end
rule "Unification Test Rule 2"
salience -10
when
f : Foo ( item != null, $item := item )
f2 : Foo ( ( item == null ) || ( item != null && $item := item ) )
then
System.out.println(String.format("%s Fired:\n\tFoo: %s\n\t%s",
kcontext.getRule().getName(), f, f2));
end
Unification Test Rule Fired:
Foo: Foo( name=foo1, item=Item( id=1 ) )
Foo( name=foo3, item=null )
Unification Test Rule Fired:
Foo: Foo( name=foo1, item=Item( id=1 ) )
Foo( name=foo1, item=Item( id=1 ) )
Unification Test Rule 2 Fired:
Foo: Foo( name=foo1, item=Item( id=1 ) )
Foo( name=foo1, item=Item( id=1 ) )
--
View this message in context:
http://drools.46999.n3.nabble.com/Unification-with-logical-or-question-tp...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:20 a.m.
Thank you for your response.
I am aware that the rule with the conditional or gets rewritten into two
separate rules and that rule is actually doing what I would expect --
producing two matches.
The main part of my question is why doesn't the second rule produce the same
results -- I was expecting two matches but it only produces one. The only
thing I can think of is that it's an order of operations issue but that
doesn't seem to make sense given the parenthesis. The second pattern in
that rule is basically:
condition || (! condition && unification)
This should produce two matches with the given data but, it doesn't produce
a match when the condition left of the || is satisfied (in that case the
unification shouldn't be happening but, maybe it is?). If I change the rule
to the following, it does produce two matches which makes me believe that
the unification is affecting things.
condition || ! condition
Thoughts?
--
View this message in context:
http://drools.46999.n3.nabble.com/Unification-with-logical-or-question-tp...
Sent from the Drools: User forum mailing list archive at Nabble.com.
11:10 a.m.
See below.
On 09/06/2012, bdolbeare <bdolbeare(a)yahoo.com> wrote:
Thank you for your response.
The main part of my question is why doesn't the second rule produce the
same
results -- I was expecting two matches but it only produces one. The only
thing I can think of is that it's an order of operations issue but that
doesn't seem to make sense given the parenthesis. The second pattern in
that rule is basically:
condition || (! condition && unification)
This should produce two matches with the given data but, it doesn't produce
a match when the condition left of the || is satisfied (in that case the
unification shouldn't be happening but, maybe it is?). If I change the
rule
to the following, it does produce two matches which makes me believe that
the unification is affecting things.
So, actually the question is: what is to be expected from
f1 : Foo ( item != null, $item := item )
and another pattern that is one of:
f2 : Foo ( item == null || item != null && $item := item ) # (a)
f2 : Foo ( item == null || $item := item ) # (b)
f2 : Foo ( item == null || item != null
) # (c)
For (a) and (b), there must be instances of Foo where one particular
item object satisfies the (remaining) constraints, whereas (c) will
fire for any Foo, since item == null || item != null reduces to true.
Unification on some Foo's item (where item != null) restricts
potential firings where the Foo instances bound to f1 and f2 point to
the same Item (which must not be null). Thus, in (a) we have one Foo
object that can be instantiated with a unified Item object. In (b),
the constraint demands an item == null, and certainly there's no way
to satisfy both, item != null and item == null.
(a) fires once, (b) doesn't fire at all, (c) fires twice.
There is, however, on open question, i.e., why a binding that is not
in the context of a Boolean expression can be written as an operand to
|| or &&. Clearly, $item := item isn't a Boolean expression, and
therefore an expression such as a > b && $item := item (item not a
Boolean) is nonsense, whereas a > b && $item := item != null is
acceptable as a shorthand.
-W
4553
days inactive
4554
days old
3 comments
2 participants
participants (2)
-
bdolbeare -
Wolfgang Laun