I did not assume that I've seen all use cases, nor that what I am a telling is the absolute truth. See no offense in my previous post. Yes, I was supposing some use case of my own experience, but please note it is the first post when you describe what you are really trying to do, ie implementing a dymanic filter configured with a web form that generates rules to do the filtering job. This is indeed highly dynamic, and for 10 rules, the cache will not be very relevant. And you are perfectly correct when you say that if rules change at each request, using a cache won't speed the process.
The cache is only usefull if the rules are stable for a time, or if only some few rules change from one time to the next one. But if you have 10 rules, compile time should not be so long, so I guess that the guy writing filtering rules is expecting very quick results (so I guess that you have few data too, otherwise the compile time would be far much smaller that processing time, especially for 10 rules ...). You want to test the adequation of drools for a use case where a user can set a set of filtering rules via a web form to filter some data somewhere ... I would say that : - If there is only simple filters you should not use drools (an in-memory DB is not so costly, at least not more than a drools' WM, and with hibernate you can write queries using a POJO-like syntax which is very close to rules' LHS) - You said that you are looking to drools to allow writing more complex rules than simple filter rules (like chaining and so on). In that case, SQL won't fit, and then you have to accept a performance overcome just because drools does much more than SQL. And to deal with that overcome, you have to think about partitionning/caching your rules (but for 10 rules, it will be difficult) _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
