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(a)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(a)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(a)lists.jboss.org [mailto:rules-users-bounces@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users