So I take it that all of these permit indexing:
<fieldname> == <literal>
<fieldname> == <variable>
<fieldname> == <qualified-identifier>
<fieldname> == <expression> # not necessarily parenthesized any more!
as well as the same using "!=".
But the following does not permit indexing:
<any RHS expression from above> == <fieldname>
Correct?
-W
On 9 May 2011 03:55, Mark Proctor <mproc...@codehaus.org> wrote:
> On 06/05/2011 07:14, Wolfgang Laun wrote:
>
> Edson,
>
> On 6 May 2011 01:14, Edson Tirelli <ed.tire...@gmail.com> wrote:
>
>>
>> Wolfgang,
>>
>> These are remaining bugs that must be fixed before final. Goal is to
>> support free form expressions as long as they return a boolean value (for
>> traditional constraints), or any value (for positional). Period.
>>
>
> (Well, as it's past 5.2.0M2...)
>
> Given that any expression is valid, will there still be a distinction
> w.r.t. efficiency, as there was with traditional constraints as opposed to
> eval()? If yes, how can I tell whether a constraint expression is "good" or
> "bad"?
>
> Only expressions that are equality constraints on direct fields are
> currently indexed.
>
> Mark
>
>
> One might assume that all legacy forms will be handled as efficiently as
> now, but it's possible that not only
> field == ($var + 1)
> but also
> field == $var + 1
> is efficient. Or, similarly,
> field == $var
> and (now) also
> $var == field
>
> But certainly not
> field - 1 == $var
> Or, at least, not until some later version ;-)
>
> I repeat this quote (from 5.2.0 Drools Introduction and General User
> Guide) and my question, what does it mean? Where is this "documented"? Is
> this somehow related to the efficiency issue?
>
> <quote>
> As previously we had to document the restricted limitations of a field
> constraint on the LHS compared to expressions used inside of an 'eval' or
> used on the RHS.
> </quote>
>
> Wolfgang
>
>
>
>>
>> Edson
>>
>> 2011/5/5 Wolfgang Laun <wolfgang.l...@gmail.com>
>>
>>> In the 5.2.0 Drools Introduction and General User Guide, there's
>>> section 2.1.3.1, Free Form expressions in Constraints (New Parser). It
>>> contains several examples:
>>> #1 Person( age * 2 > $anotherPersonsAge + 2 )
>>> #2 Person( addresses["home"].streetName.startsWith( "High Park" ) )
>>> #3 Person( isAdult() )
>>>
>>> #1 does not compile: Unable to build constraint as 'age * 2' is invalid
>>> : [Rule name='exa1']
>>>
>>> #2 works - although I'd very much prefer not to be swamped with MVEL
>>> extensions unless I ask for it.
>>>
>>> #3 does not compile: Unable to Analyse Expression isAdult():
>>> [Error: no such identifier: isAdult]
>>> [Near : {... isAdult() ....}]
>>>
>>> Neither rule name nor line number is provided.
>>>
>>> Would it please be possible to have a precise statement what one *can*write
>>> as a constraint?
>>>
>>>
>>> <quote>
>>> As previously we had to document the restricted limitations of a field
>>> constraint on the LHS compared to expressions used inside of an 'eval' or
>>> used on the RHS.
>>> </quote>
>>>
>>> I'm sorry, but I do not understand the meaning of this sentence. What
>>> does it mean, please?
>>>
>>> Cheers
>>> Wolfgang
>>>
>>>
>>
>
> _______________________________________________
> rules-dev mailing
> listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
