[rules-users] qualified identifiers in constraints: not commutative?

[Wolfgang Laun]

On 31 December 2010 19:05, Michael Whidden <mwhidden at 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 at thebluew.com
> > <mailto:mwhidden at 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 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
>
> _______________________________________________
> 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/20101231/fe98b1f8/attachment.html