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 <mproc...@codehaus.org
<mailto: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
<mailto: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.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.l...@gmail.com
<mailto: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 list
rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org <mailto: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
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
