[rules-users] Contains substring in the LHS with regular expression capturing groups?

Edson Tirelli tirelli at post.com
Fri Dec 14 10:06:28 EST 2007 

   The difference is not in sharing the nodes, but in indexing... although,
today, only "==" constraints are indexed.
   So, "matches" operator is really just syntax sugar on String.matches()
method call.
   In other words, if you have 2 rules with identical eval() calls, they may
be shared, the same way that if you have 2 rules with identical "matches"
call. Although, none of them is indexed and if we implement optimizations in
the future drools versions, "matches" is more likely to be optimized than
eval.

    Edson

2007/12/14, Waruzjan Shahbazian <wshahbazian at xiam.nl>:
>
> The pluggable operators example looks very cool  :-) , I just have one
> more question about the performance. I suppose that if I use eval() with
> indexOf(), there would be no caching? Isn't that one of the benefits of
> using the "drools" operators, since ( if they work on the same way as in
> the example in the trunk anyway) they do use caching. Anyway, if  I do
> some benchmarks about this I would let you now!
>
> About the backwards compatibility: Thats cool, as long as what I did was
> not a not recommended way. The costes for the few possible changes in
> the feature are indeed affordable to pay.
>
> Waruzjan
>
> Edson Tirelli schreef:
> >    I really don't know about perf differences in this case. I guess best
> > thing would be for you do give a try (and let us know please). :) It
> > probably will depend on the java implementation of the matches() against
> > indexOf() method. I guess indexOf is faster, but don't know if it is
> > significant difference.
> >    Regarding pluggable operators, here you have one example:
> >
> >
> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-core/src/main/java/org/drools/base/evaluators/MatchesEvaluatorsDefinition.java
> >
> >     Regarding using the descriptor classes, I would say it is the
> > recommended way for generated rules, since you avoid the "text
> > generation"+"parsing" cost of the rules. Although, as much as we try to
> keep
> > backward compatibility, we can't guarantee there will be no breaks,
> since we
> > are always adding new features and the descriptor model must usually
> change
> > to support them what may eventually break backward compatibility. Even
> with
> > that, I think it is an affordable cost to pay (fixing eventual breaks on
> > version updates) compared to your runtime application robustness.
> >
> >    []s
> >    Edson
> >
> >
> >
> > 2007/12/14, Waruzjan Shahbazian <wshahbazian at xiam.nl>:
> >
> >> Hi,
> >>
> >> Thanks for the reply. I wanted to be sure that there wasn't any more
> >> efficient way to check a substring in a string, or do you think that
> >> eval() with a indexOf() call would be more efficient than matches()
> with
> >> regular expression?. Since I can't group the results, the speed is the
> >> only issue here.
> >>
> >> In my application I am creating the PackageDescr myself with some
> >> "template" RuleDescr's (which are being filled in with the, limited,
> >> user input in the Swing GUI) and the package is being build with the
> >> builder. If the regular expression methode in the matches operator is
> >> the best way to check a substring in a string, I can use variabeles
> >> (which are the user inputs) to fill the regular expression. So I don't
> >> really need a new operator for this. But I am interessted how the
> >> development of a new operator would be, so maybe you could tell me
> where
> >> I need to be to do so :-) .
> >>
> >> In the attachment  is the classe diagram of the PackageDescr with the
> >> linked classes as I have understood and used in my application. Of
> >> course not every operation and attribute is included, but maybe this
> >> could be helpfull for someone else who wants to create PackageDescr's
> >> directly.
> >>
> >> I suppose the public methodes used in this operation are going to be
> >> supported by the following drools versions? Or should I have used the
> >> DRL and XML ? =-O
> >>
> >> Thanks,
> >>
> >> Waruzjan
> >>
> >> Edson Tirelli schreef:
> >>
> >>>    Yes, you may use matches. The other alternative is using an eval
> and
> >>>
> >> a
> >>
> >>> regular indexOf() call to check for the existance of the substring.
> >>>
> >> Drools
> >>
> >>> up to versions 4.0.x is JSE 1.4 compliant, so you can't use contains()
> >>> method.  In trunk, you may also develop your own operator and plug it
> >>>
> >> into
> >>
> >>> the engine... although, it is not documented yet, but if you want to
> >>>
> >> try, I
> >>
> >>> can guide you through. And if you want to contribute docs after that,
> >>>
> >> even
> >>
> >>> better. :)
> >>>
> >>>    It is not possible to capture groups and reuse in the RHS. I'm
> >>>
> >> thinking
> >>
> >>> about a way to bind variables to arbitrary values in the LHS. If we
> >>> implement that, than it would be possible for you to do that, but not
> >>> possible at this moment.
> >>>
> >>>    Edson
> >>>
> >>> 2007/12/14, Waruzjan Shahbazian <wshahbazian at xiam.nl>:
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>> I need to check in the LHS of my rule if  a given String contains an
> >>>> given substring. What is the best way to do that? I can use regular
> >>>> expression with matches, but is that the best (fastest) solution?
> >>>> (STRING matches "(?i).*SUBSTRING.*"). And can I use regulare
> >>>>
> >> expressions
> >>
> >>>> capturing groups and than use the results of the groups in the RHS?
> If
> >>>> not, what is the best methode to do that?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Waruzjan
> >>>> _______________________________________________
> >>>> rules-users mailing list
> >>>> rules-users at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/rules-users
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------
> >>>
> >>> _______________________________________________
> >>> rules-users mailing list
> >>> rules-users at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/rules-users
> >>>
> >>>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >>
> >>
> >>
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
  Edson Tirelli
  JBoss Drools Core Development
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20071214/01a1c3b5/attachment.html

More information about the rules-users mailing list