[rules-users] Is there a faster way of doing this in Drools ?

[GPatel at tsys.com]

so you are using drools to build on-the-fly queries based on user input. 
You could probably do this via "static" rules. Since you basically have 4 
variables (price, avg_user_rating, num_ratings, category), you could write 
4 rules, one each that filters based on one of the 4 variables and then 
chain the execution through salience:

rule price:
salience 1
when 
        $p: Product(price in param)
then
        add $p to result

rule avg_user_rating:
salience 2
when
        $p: Product(avg_user_rating > param)
then
        add $p to result


and so on




From:   soumya_sd <soumya_sd at yahoo.com>
To:     rules-users at lists.jboss.org, 
Date:   05/09/2012 08:43 AM
Subject:        Re: [rules-users] Is there a faster way of doing this in 
Drools ?
Sent by:        rules-users-bounces at lists.jboss.org




Vincent Legendre wrote
> 
> Users changing rules IS the correct use-case of drools (I would even say
> that if rules never change, drools is likely to be worse than pure 
java).
> What others said is "changing the rules at each request by regenerating
> and recompiling" is not.
> 
> I can't imagine that users may change rules at each request, so you must
> have, at least for some time (thus a lot of requests), a stable rule 
base.
> What is costly is to compile rules, but you already know that.
> So the idea is to keep in some kind of cache the actual rules, and only
> recompile them when they change.
> 
> The source of rules does not matter : you can generate the DRL according
> to your configuration, or make you users directly write rules (with
> guvnor, which will fits well if your rules are only basic filters).
> 
> The optimisation you have to do is to keep your compiled rules somewhere
> (by serializing your KnowlegdePackages or simply keep it in a kind of
> map), and reuse it until your source change : you have to find a way to
> detect that rules (or the config that is used to generate them) have
> changed, and then recompile a new up-to-date KnowledgePackage.
> 
> 

Thank you for your insights. 

At this point I'm designing for the worst case i.e., I'm assuming the 
rules
with change with every request. 

Moreover, this can happen on a regular basis in the system I'm trying to
design. 

Product
{ 
  price
  ave_user_rating
  num_ratings
  category 
 
} 

User wants to see Product with with the following rules 

at t=t_1 : If product.category in {A,B}. 

at t=t_2 : If product.category in {A,B} AND price < 100 

at t=t_3 :  If product.category in {A,B}  AND price < 100 AND num_ratings 
>
100 

You can imagine the user changing these rules in a span of less than a
minute. 

I understand that Drools is designed for cases when rules changes often. 
But
can it support something like the one I described above where rules are
changing at a much faster rate? 


Thanks. 






--
View this message in context: 
http://drools.46999.n3.nabble.com/Is-there-a-faster-way-of-doing-this-in-Drools-tp3973888p3974483.html

Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users



-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120509/f7278c98/attachment.html