[rules-dev] Constraint efficiency: (was: "New in 5.2.0" - What works, what doesn't?)

[Mark Proctor]

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