[rules-users] calls to 'Helper' classes in LHS - are they all owed?

Olenin, Vladimir (MOH) Vladimir.Olenin at moh.gov.on.ca
Tue Feb 13 15:01:43 EST 2007


Thanks, Mark. Are there any plans on making return value, predicate and eval
expressions indexable (in case it is possible at all)? Would it be included
in 3.2 release? I understand that DROOLS can not guarantee that helper
method will return the same value each time and probably that's why excludes
such cases from index, but the same goes for 'getters' of the fact objects -
DROOLS can't guarantee the getter will return the same value each time, so
it just have to assume it (and it is outlined in the documentation).

 

There are a few use case that might need this kind of functionality, eg to
cache the results of 'associative' lookup. Especially for the 'Decision
Tables'. The problem I'm facing right now is I need to 'expand' the list of
codes based on some id and use those codes as constraint:

 

            MyObject(field <= LookupMap.getCodes($param))

 

Where $param is a value from Decision Table data. In this particular case a
set of, say 100 codes, can be described with a simple ID. For more complex
cases a pseudo 'set select' expression can be passed as a parameter (eg,
LookupMap.getCodes("groupId_1 - grouperId_2"), which should return the
intersection of codes in groupId_1 and groupId_2). In any case, the <key,
value> pairs returned by LookupMap class would remain the same.

 

Vlad

 

  _____  

From: rules-users-bounces at lists.jboss.org
[mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Mark Proctor
Sent: 12 February 2007 19:16
To: Rules Users List
Subject: Re: [rules-users] calls to 'Helper' classes in LHS - are they
allowed?

 

We were hoping the community would work with us and improve the
documentation over the last year - to date we have had zip :( We will have
another documentation drive once we get to the candidate release stage for
the current development cycle. We simply don't have the cycles to work on a
book, with any luck after we spend 3 to 4 weeks on documentation during hte
candidate release stage it should get better, and maybe one day  the manual
can form the basis of a book. Some ideas for the  community to work include
the examples in drools-examples, they can even use what I did for drools 2.x
as a starting basis, or to provide a really good tutorial on the basics of
pattern matching, you can look the public domain clips manual for pointers
here. It's not money we need, its time, YOUR time :)

If you want to use a helper class it must be in a return value, predicate or
eval - none of which are currently indexed. return value and predicate must
also be time constant, eval does not have to be.

Mark
Michael Suzio wrote: 

I see this in the docs:

"A d0e1997Predicate 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



On 2/12/07, Steven Williams <stevenw at objectconsulting.com.au
<mailto:stevenw at objectconsulting.com.au> > wrote: 

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 < <mailto:msuzio at gmail.com>  msuzio at 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 at moh.gov.on.ca
<mailto:Vladimir.Olenin at 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 at lists.jboss.org <mailto:rules-users at lists.jboss.org> 
https://lists.jboss.org/mailman/listinfo/rules-users
<https://lists.jboss.org/mailman/listinfo/rules-users> 

 


_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org  <mailto:rules-users at lists.jboss.org> 
https://lists.jboss.org/mailman/listinfo/rules-users
<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 at objectconsulting.com.au  <mailto:stevenw at objectconsulting.com.au> 
www.objectconsulting.com.au <http://www.objectconsulting.com.au> 

consulting | development | training | support
our experience makes the difference 
_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org> 
https://lists.jboss.org/mailman/listinfo/rules-users
<https://lists.jboss.org/mailman/listinfo/rules-users> 





 





  _____  



 
_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org> 
https://lists.jboss.org/mailman/listinfo/rules-users
<https://lists.jboss.org/mailman/listinfo/rules-users> 
  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070213/bd915c3e/attachment.html 


More information about the rules-users mailing list