I see this in the docs:
"A Predicate constraint can use any valid Java expression
as long as it evaluated to a primitive boolean - avoid using any
Drools keywords as Declaration identifiers. Previously bound
declarations can be used in the expression. Functions used in a
Predicate Constraint must return time constant results."
and under the discussion of 'eval':
"Evals cannot be indexed and thus are not as optimal as using Field
Constraints."
and this in general discussion of constraints and accessors of your objects used in them:
"Do please make sure that you are accessing methods that take no
parameters, and are in-fact "accessors" (as in, they don't change the
state of the object in a way that may effect the rules - remember that
the rule engine effectively caches the results of its matching inbetween
invocations to make it faster)."
So, if invoking a helper method is like an eval, I'm thinking Drools computes the match, but then throws it away because it knows this is not a constant expression. Whereas, if it were just a match of an accessor's value vs. a constant String, it could cache that.
I'm wildly speculating, only because I want to understand fully what is happening, so I'm throwing stuff out there so the Drools team will have to correct my misapprehensions before I confuse the whole list (*g*). Sometimes reading the Drools documentation is like a Talmudic scholar trying to find the deeper meaning of the sacred words... as much as I want the
3.2 milestone, I want real documentation even more (and *hint hint* -- would probably be willing to pay for it, guys! Can we get an O'Reilly book?)
--- Michael
I believe there is a caveat on functions and helper methods called from the LHS that they need to be constant over time (or at least over the life of the working memory) which then allows matches to be computed as per normal.
Steve--On 2/13/07, Michael Suzio < msuzio@gmail.com> wrote:The JBoss guys can correct me if I'm wrong, but although I think that works, what you've just done is eliminate any chance to precompute matches and trim down the checks that need to happen to find a rule match. Since the engine can't know that Helper.transform("value") returns a constant value, it has to re-run that every time and it has to reject for matches to the rule constraint every time.
I'm sure this would really sink performance, in other words. You can easily see the effect -- write the rule this way and time it, and then write it with the return value of Helper.transform being inlined, and I'm sure there's a big difference. It's the same as any other eval(...) situation in Drools; possible, but not good for performance.On 2/12/07, Olenin, Vladimir (MOH) <Vladimir.Olenin@moh.gov.on.ca> wrote:Hi,
I was wondering if calls to a Helper class are allowed in LHS of the rule?
Eg:
Rule myRule
When
MyObject(objField == Helper.transform("value"))
Then
// smth
End
Thanks,
Vlad
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Steven Williams
Supervising Consultant
Object Consulting
Office: 8615 4500 Mob: 0439 898 668 Fax: 8615 4501
stevenw@objectconsulting.com.au
www.objectconsulting.com.au
consulting | development | training | support
our experience makes the difference
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users