4:32 a.m.
I notice an unexpected behavior when creating a technical DRL in Guvnor.
If I have a fact with a sub-fact, then binary operators don't seem to be
commutative.
Eg.,
declare Broker
maxQ: Integer
declare Order
q: Integer
b: Broker
The rule
$o:Order($o.b.maxQ < $o.q)
validates fine, but
$o:Order($o.q > $o.b.maxQ)
returns an error "Unable to create restriction
'[QualifiedIndentifierRestr: > $o.broker.maxQ ]' for field '$o.q' in
the
rule"
I'm new, so I want to make sure I'm not missing something obvious here...
1:30 a.m.
At Mr. Legendre's suggestion, I removed the $o from my constraints, but
with the same result: (b.maxQ < q) works, but (q > b.maxQ) fails. I get
the error:
"Unable to create restriction '[QualifiedIndentifierRestr: < b.maxQ ]'
for field 'quantity' in the rule 'MaxQty'"
On 12/30/2010 2:32 PM, Michael Whidden wrote:
I notice an unexpected behavior when creating a technical DRL in
Guvnor.
If I have a fact with a sub-fact, then binary operators don't seem to be
commutative.
Eg.,
declare Broker
maxQ: Integer
declare Order
q: Integer
b: Broker
The rule
$o:Order($o.b.maxQ < $o.q)
validates fine, but
$o:Order($o.q > $o.b.maxQ)
returns an error "Unable to create restriction
'[QualifiedIndentifierRestr: > $o.broker.maxQ ]' for field '$o.q' in
the
rule"
I'm new, so I want to make sure I'm not missing something obvious here...
1:47 a.m.
Try parenthesizing the right hand side but note that you may have to use
getters to access the fields
$o:Order($o.q > ($o.getB().getMaxQ() ) )
It's possible that using dialect "mvel" might be a way to avoid using the
getX() instead of x.
-W
On 31 December 2010 17:30, Michael Whidden <mwhidden(a)thebluew.com> wrote:
At Mr. Legendre's suggestion, I removed the $o from my
constraints, but
with the same result: (b.maxQ < q) works, but (q > b.maxQ) fails. I get
the error:
"Unable to create restriction '[QualifiedIndentifierRestr: < b.maxQ ]'
for field 'quantity' in the rule 'MaxQty'"
On 12/30/2010 2:32 PM, Michael Whidden wrote:
> I notice an unexpected behavior when creating a technical DRL in Guvnor.
>
> If I have a fact with a sub-fact, then binary operators don't seem to be
> commutative.
>
> Eg.,
>
> declare Broker
> maxQ: Integer
>
> declare Order
> q: Integer
> b: Broker
>
> The rule
> $o:Order($o.b.maxQ < $o.q)
> validates fine, but
> $o:Order($o.q > $o.b.maxQ)
> returns an error "Unable to create restriction
> '[QualifiedIndentifierRestr: > $o.broker.maxQ ]' for field '$o.q'
in the
> rule"
>
> I'm new, so I want to make sure I'm not missing something obvious here...
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:05 a.m.
New subject: qualified identifiers in constraints: not commutative?
Thank you! That fixes it, without using getter methods. So did I make a
mistake, or is this a workaround for a bug?
These work:
$o:Order(q > (b.maxQ))
$o:Order($o.q > ($o.b.maxQ))
$o:Order(b.maxQ > q)
$o:Order($o.b.maxQ > $o.q)
These don't:
$o:Order(q > b.maxQ)
$o:Order($o.q > $o.b.maxQ)
Is this proper behavior, or a bug? I can't find anything in the docs
that describes the parens as required when a qualified identifier
appears on the right side of a binary operator in a constraint.
On 12/31/2010 11:47 AM, Wolfgang Laun wrote:
Try parenthesizing the right hand side but note that you may have to
use
getters to access the fields
$o:Order($o.q > ($o.getB().getMaxQ() ) )
It's possible that using dialect "mvel" might be a way to avoid using
the getX() instead of x.
-W
On 31 December 2010 17:30, Michael Whidden <mwhidden(a)thebluew.com
<mailto:mwhidden@thebluew.com>> wrote:
At Mr. Legendre's suggestion, I removed the $o from my constraints, but
with the same result: (b.maxQ < q) works, but (q > b.maxQ) fails. I get
the error:
"Unable to create restriction '[QualifiedIndentifierRestr: < b.maxQ
]'
for field 'quantity' in the rule 'MaxQty'"
On 12/30/2010 2:32 PM, Michael Whidden wrote:
> I notice an unexpected behavior when creating a technical DRL in
Guvnor.
>
> If I have a fact with a sub-fact, then binary operators don't
seem to be
> commutative.
>
> Eg.,
>
> declare Broker
> maxQ: Integer
>
> declare Order
> q: Integer
> b: Broker
>
> The rule
> $o:Order($o.b.maxQ < $o.q)
> validates fine, but
> $o:Order($o.q > $o.b.maxQ)
> returns an error "Unable to create restriction
> '[QualifiedIndentifierRestr: > $o.broker.maxQ ]' for field
'$o.q'
in the
> rule"
>
> I'm new, so I want to make sure I'm not missing something obvious
here...
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5:18 a.m.
On 31 December 2010 19:05, Michael Whidden <mwhidden(a)thebluew.com> wrote:
Thank you! That fixes it, without using getter methods. So did I make
a
mistake, or is this a workaround for a bug?
Very careful reading of the very, very small print in the Expert manual
section describing the various forms of field constraints will tell you that
one of the forms of single value restrictions is the "Return Value
Restriction", a parhenthesized expressiion, which is the form where any Java
expression is permitted. (The alternatives use either a literal, a variable
or a qualified identifier. Your construct would qualify syntactically for
the latter - I'm not sure where the current Drools version draws the line;
future releases might relax this limitation.)
Seemingly unnecessary parentheses are the distinction for the Drools parser
to throw the contents into the generated Java code "as is".
-W
These work:
$o:Order(q > (b.maxQ))
$o:Order($o.q > ($o.b.maxQ))
$o:Order(b.maxQ > q)
$o:Order($o.b.maxQ > $o.q)
These don't:
$o:Order(q > b.maxQ)
$o:Order($o.q > $o.b.maxQ)
Is this proper behavior, or a bug? I can't find anything in the docs
that describes the parens as required when a qualified identifier
appears on the right side of a binary operator in a constraint.
On 12/31/2010 11:47 AM, Wolfgang Laun wrote:
> Try parenthesizing the right hand side but note that you may have to use
> getters to access the fields
> $o:Order($o.q > ($o.getB().getMaxQ() ) )
>
> It's possible that using dialect "mvel" might be a way to avoid using
> the getX() instead of x.
>
> -W
>
>
> On 31 December 2010 17:30, Michael Whidden <mwhidden(a)thebluew.com
> <mailto:mwhidden@thebluew.com>> wrote:
>
> At Mr. Legendre's suggestion, I removed the $o from my constraints,
but
> with the same result: (b.maxQ < q) works, but (q > b.maxQ) fails. I
get
> the error:
> "Unable to create restriction '[QualifiedIndentifierRestr: < b.maxQ
]'
> for field 'quantity' in the rule 'MaxQty'"
>
>
>
> On 12/30/2010 2:32 PM, Michael Whidden wrote:
> > I notice an unexpected behavior when creating a technical DRL in
> Guvnor.
> >
> > If I have a fact with a sub-fact, then binary operators don't
> seem to be
> > commutative.
> >
> > Eg.,
> >
> > declare Broker
> > maxQ: Integer
> >
> > declare Order
> > q: Integer
> > b: Broker
> >
> > The rule
> > $o:Order($o.b.maxQ < $o.q)
> > validates fine, but
> > $o:Order($o.q > $o.b.maxQ)
> > returns an error "Unable to create restriction
> > '[QualifiedIndentifierRestr: > $o.broker.maxQ ]' for field
'$o.q'
> in the
> > rule"
> >
> > I'm new, so I want to make sure I'm not missing something obvious
> here...
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:50 a.m.
New subject: qualified identifiers in constraints: not commutative?
Thanks again, but your read of the "small print" perhaps explains why
the parens make (o.q > (o.b.maxQ)) work, but does not explain why
(o.q > o.b.maxQ) does not work while (o.b.maxQ < o.q) does work.
On 12/31/2010 3:18 PM, Wolfgang Laun wrote:
On 31 December 2010 19:05, Michael Whidden <mwhidden(a)thebluew.com
<mailto:mwhidden@thebluew.com>> wrote:
Thank you! That fixes it, without using getter methods. So did I make a
mistake, or is this a workaround for a bug?
Very careful reading of the very, very small print in the Expert manual
section describing the various forms of field constraints will tell you
that one of the forms of single value restrictions is the "Return Value
Restriction", a parhenthesized expressiion, which is the form where any
Java expression is permitted. (The alternatives use either a literal, a
variable or a qualified identifier. Your construct would qualify
syntactically for the latter - I'm not sure where the current Drools
version draws the line; future releases might relax this limitation.)
Seemingly unnecessary parentheses are the distinction for the Drools
parser to throw the contents into the generated Java code "as is".
-W
These work:
$o:Order(q > (b.maxQ))
$o:Order($o.q > ($o.b.maxQ))
$o:Order(b.maxQ > q)
$o:Order($o.b.maxQ > $o.q)
These don't:
$o:Order(q > b.maxQ)
$o:Order($o.q > $o.b.maxQ)
Is this proper behavior, or a bug? I can't find anything in the docs
that describes the parens as required when a qualified identifier
appears on the right side of a binary operator in a constraint.
On 12/31/2010 11:47 AM, Wolfgang Laun wrote:
> Try parenthesizing the right hand side but note that you may have
to use
> getters to access the fields
> $o:Order($o.q > ($o.getB().getMaxQ() ) )
>
> It's possible that using dialect "mvel" might be a way to avoid
using
> the getX() instead of x.
>
> -W
>
>
> On 31 December 2010 17:30, Michael Whidden <mwhidden(a)thebluew.com
<mailto:mwhidden@thebluew.com>
> <mailto:mwhidden@thebluew.com <mailto:mwhidden@thebluew.com>>>
wrote:
>
> At Mr. Legendre's suggestion, I removed the $o from my
constraints, but
> with the same result: (b.maxQ < q) works, but (q > b.maxQ)
fails. I get
> the error:
> "Unable to create restriction '[QualifiedIndentifierRestr: <
b.maxQ ]'
> for field 'quantity' in the rule 'MaxQty'"
>
>
>
> On 12/30/2010 2:32 PM, Michael Whidden wrote:
> > I notice an unexpected behavior when creating a technical DRL in
> Guvnor.
> >
> > If I have a fact with a sub-fact, then binary operators don't
> seem to be
> > commutative.
> >
> > Eg.,
> >
> > declare Broker
> > maxQ: Integer
> >
> > declare Order
> > q: Integer
> > b: Broker
> >
> > The rule
> > $o:Order($o.b.maxQ < $o.q)
> > validates fine, but
> > $o:Order($o.q > $o.b.maxQ)
> > returns an error "Unable to create restriction
> > '[QualifiedIndentifierRestr: > $o.broker.maxQ ]' for field
'$o.q'
> in the
> > rule"
> >
> > I'm new, so I want to make sure I'm not missing something obvious
> here...
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
<mailto:rules-users@lists.jboss.org
<mailto:rules-users@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4876
days inactive
4877
days old
6 comments
3 participants
participants (3)
-
Michael Whidden -
Vincent Legendre -
Wolfgang Laun