[rules-users] Using JBoss Rules for implementing "sparse" lookuptables

Alexander Varakin avarakin at optonline.net
Mon Feb 19 20:26:52 EST 2007


Alan,

Thanks for your reply!
The main reason I was considering creating a rule per row is because it
allows "flexible" matching: it will allow matching records with
different level of details.
I was also thinking of asserting rows of my lookup table as facts, would
that work? What kind of performance should I expect in this case?

Alex

Ho, Alan wrote:
> Drools 3.1 has the a new conditional element called "from". You can do queries on your database (hibernate) or any other data structure:
>
> e.g. $r : Restaurant( $postCode ) from hbSession.getNamedQuery( "some query" ).setProperties( [ key1 : value2, key2 : value ] ).list()
>
> The "rule per row" doesn't work very well. I've had a discussion with Michael Neale about this and got some good advice. I've added my conversation with Michael below.
>
> Regards,
> Alan Ho
>
>
> See this thread:
>
> --------------------------------------------------------------------------------
> From: Michael Neale  
>
> yeah you can emulate backwards type chaining approaches by writing rules who assert "control facts" like
>
> assert(new RequestLookup("key info"));
>
> - there is then another rule which actually performs the lookup, and pulls the data from the DB, and asserts it into the working memory as needed (and retracts the request control fact). 
>
>
>
>
> On 6/20/06, Ho, Alan <alanho at amazon.com> wrote:
> Thanks !!!
>  
> It makes a lot of sense to have a set of rules to load facts, and another set of rules to operate on those facts. 
>  
> Regards,
> Alan Ho
>
>
>
> --------------------------------------------------------------------------------
> From: Michael Neale  
> Sent: Thursday, June 15, 2006 4:46 PM
> To: Ho, Alan
> Subject: Re: Dealing with thousands of rules
>
>
> Hi Alan. 
>
> Yes I think follow what you are saying. On a practical note, many many thousands of rules would hurt, as at present java semantics are compiled into little classes behind the scenes (and JVMs can only take so much !) - soon - if no java semantics are used, no java classes will be created so that problem goes away. 
>
> Still, millions of rules doesn't feel right does it. There are often ways you can rewrite it so that you just have a few rules, but millions of facts (hard to explain in abstract !) - so you have a rule that joins 2 unrelated facts together, and asserts the combination, and another rule that handles that combination. but anyway... 
>
> I think when you are talking about data wrangling like this, SQL DBs are the best proven system in the world, so its sensible to use it.
> Backwards chaining maybe: you can simulate this now by having a "RequestForData" fact object, and a rule that responds to one of those objects, and then runs the query to retrieve the results - this is kind of how Jess "compiles in" backward chaining support (we will probably do something different - more like prolog from what Mark tells me). 
>
> BUT, Mark has been working in his spare time in a "from" keyword feature, so it can reason over facts that are not in working memory (like from a database) - yet do all the usual things. 
> Some thing like 
> when 
>   r: RequestingCustomer() from lookup.getCustomers()
>
> with lookup being some global utility you pass in, or else another bound fact, anything really (its like JRules). It saves asserting lots of things into working memory. 
> Not sure how this would exactly solve your problem, as I haven't quite understood it. But at the end of the day, I think perhaps having that database table is sensible - even if you had a to have a pure java system, HSQLDB could easily cope with that sort of load (all in memory) - SQL DBs are born for that stuff ! 
>
> Does that help at all? 
>
>
> On 6/16/06, Ho, Alan <alanho at amazon.com> wrote: 
> Hi Michael, 
>
> I've been quite interested with the Jboss Rules project for a while now, but I'm running into a use case that is not quite working out for our team.
>
>
>
> Imagine a service that controls what kind of books people can buy : 
>
> Here is the rule that I want to implement: 
>
> when 
>         RequestingCustomer == "Sally" and interestingBook = "Bible" 
> then 
>         RequestingCustomer can by  interestingBook 
> end 
>
>
>
> The problem is there maybe thousands of customers and thousands of books, hence potentially millions of rules. Instead to implement the rule, we end up having to use a SQL statement: 
>
> when 
>         eval( (ExecuteSQL(select count(*) from CustomerRuleTable where customer = RequestingCustomer and book=interestingBook)) > 1 )
>
> then 
>         RequestingCustomer can by interestingBook 
> End 
>
> The CustomerRuleTable will only have two columns -> customer and book. 
>
> I wish there was a way to implement this more elegantly ( backwards chaining ?). 
>
> Thanks, 
> Alan Ho 
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: rules-users-bounces at lists.jboss.org [mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Alexander Varakin
> Sent: Monday, February 19, 2007 2:41 PM
> To: Drools Users List
> Subject: [rules-users] Using JBoss Rules for implementing "sparse" lookuptables
>
> Hi,
>
> I am thinking of using JBoss Rules for implementing "sparse" lookup tables, e.g. suppose I have a lookup table which contains data like this:
>
> PostalCodeOrZIP StateOrProvince Country  DistanceFromNorthPole 
> 07645    NJ   USA    1200
> -            NJ   USA    1100
> -            -     USA    1000
> -         Ontario  CA  600
> -         -     CA        500
>
> The objective is to find a best matching row in the table, given PostalCodeOrZIP, StateorProvince and Country and return DistanceFromNorthPole.
> Another variation is just try to find a matching row in the table and return true if row is found.
> Note that some records may have fields with omitted values, e.g. if we know ZIP code, then we dont need to know state.
> Also we may have incomplete data, e.g. for some countries there will be only one row for the entire country, and some countries may not have any rows.
>
> Very important requirement is that the lookup table may grow up to 100K rows.
>
> It looks like this objective can be easily accomplished by translating the lookup table  into a rule set with a rule per row in the table and then use pattern matching of JBoss Rules for matching the rows.
>
> My only concerns is that such implementation may consume too much memory, considering that I will need to build ruleset with 100K rules. 
> Could somebody let me know whether using JBoss Rule for this task is a good idea and give some ideas on optimizing memory consumption. 
>
> Thanks,
> Alex
>
>
> _______________________________________________
> 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
>
>   




More information about the rules-users mailing list