[rules-dev] Constraint efficiency: (was: "New in 5.2.0" - What works, what doesn't?)
Mark Proctor
mproctor at codehaus.org
Mon May 9 09:56:45 EDT 2011
On 09/05/2011 12:40, Wolfgang Laun wrote:
>
> So I take it that all of these permit indexing:
> <fieldname> == <literal>
yes
> <fieldname> == <variable>
yes
> <fieldname> == <qualified-identifier>
yes
> <fieldname> == <expression> # not necessarily parenthesized any more!
no, not yet, but will do eventually. We can only indexed direct
accessors at the moment - pure literals and variables. No different than
other 5.x releases. Over time we hope to improve what can be indexed.
> as well as the same using "!=".
It's not possible to indexed !=
>
> But the following does not permit indexing:
> <any RHS expression from above> == <fieldname>
I don't understand this question as there is no join process in the RHS,
and thus no possible indexing.
Mark
>
> Correct?
>
> -W
>
>
> On 9 May 2011 03:55, Mark Proctor <mproctor at codehaus.org
> <mailto:mproctor at codehaus.org>> wrote:
>
> On 06/05/2011 07:14, Wolfgang Laun wrote:
>> Edson,
>>
>> On 6 May 2011 01:14, Edson Tirelli <ed.tirelli at gmail.com
>> <mailto:ed.tirelli at 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.0Drools 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.laun at gmail.com
>> <mailto:wolfgang.laun at 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 list
>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110509/125d7fbf/attachment-0001.html
More information about the rules-dev
mailing list