[rules-users] Contains substring in the LHS with regular expression capturing groups?
Edson Tirelli
tirelli at post.com
Fri Dec 14 10:08:20 EST 2007
Oh, and I missed another important difference: eval() always generates
code in java dialect, while operators are resolved directly, without the
need to generate code... so besides syntax sugar, there is a small gain in
compilation time performance.
[]s
Edson
2007/12/14, Edson Tirelli <tirelli at post.com>:
>
>
> 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
>
--
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/077d0455/attachment.html
More information about the rules-users
mailing list