What you need here is to use a control object, probably something called
"Search". Basically a Search object would record how many query attempts have
been made, the one(s) that succeeded, and the results of the successful search(es).
Basic properties for the Search object could be:
String category;
String product;
int attempts; //How many times the DB has been queried
Using this control object, you can create rules that manage the search process, from the
most general to the most specific.
These rules assume that a Search object is retracted from working memory when it's
sent to a query processor, and asserted again (with attempts and failures incremented
accordingly) after the query is done. Search objects would only be asserted again after
success if you want to do something complex with them at that point. (i.e. not just
reporting raw results)
Here are some sample rules for managing all Searches
rule "MaxAttempts"
when
s: Search(attempts > MAX_ATTEMPTS)
then
//EPIC FAIL!
retract(s);
processEpicFail(s);
end
rule "Send search"
salience <lower priority than anything else>
when
//Just matches automatically once higher priority rules finish
s: Search();
then
retract(s);
processSearch(s);
end
For handling specific types of search, you could have subclasses of the Search object,
with getters and setters for specific search criteria. The Search superclass itself
should return these criteria in a generic way so the search engine can create a query for
them. Some examples for a WidgetSearch subclass:
rule "WidgetAttempt3"
when
s: WidgetSearch(attempt >= 3)
then
//widen length property search by [-1,+1]
end
rule "WidgetAttempt7"
when
s: WidgetSearch(attempt >= 7)
then
//widen width property search by [-1,+1]
end
Note that on the 7th and later attempts, both WidgetAttempt3 and WidgetAttempt7 rules will
fire.
In addition, you could have Search subclasses implement interfaces that classify the type
of search, and have rules that handle them similarly across the board. For example, take
interface EncryptedThing with method "Set<String>
getEncryptionCriteria()":
rule "AddDES"
when
s: EncryptedThing(attempt >= 2)
then
s.getEncryptionCriteria().add("DES");
end
So all searches on encrypted things will include DES after the 3rd attempt.
Each Search altering rule can be as specific or general as you like. You don't need a
seperate rule for each combination of type/attempt/whatever so this prevents any
combinatorial explosion of rules. And the above example doesn't examine existing
Search contents to decide what to search next, which is also a (more complex) option.
However those avenues of complexity are available to you. You could even continue search
if some attempts are successful, and only halt when the results match some criteria.
--- On Tue, 3/24/09, Alessandro Terrinoni <aleterrinoni(a)hotmail.com> wrote:
From: Alessandro Terrinoni <aleterrinoni(a)hotmail.com>
Subject: [rules-users] Use of Drools for a product catalog retrieval in a best effort
fashon
To: rules-users(a)lists.jboss.org
Date: Tuesday, March 24, 2009, 10:50 AM
Hello.
I'm working on a project about a product catalog, which
involves the use of Drools for fetching from the database
layer a set of products that support a list of
characteristics in a best-effort fashon
In detail the database is constructed with the use of
dynamic characteristics, i.e. all attributes, like
dimensions or weight, are not included as fields in the
table cointaining the definition of the product but they are
stored in a different table; then the linkage
product-characteristic is stored in a third table cointaning
the product id, the characteristic id and the value
associated and other necessary fields.
Now i would use drools for getting a limited number
(let's say fixed - i.e. everytime max 10) products which
has a variable number of characteristic (supplied by the
user) in a best-effort style. For example if i search a
router with 5 ports i could retrieve also routers with 6 or
4 ports if no router with 10 ports are in the database or
there are less then 10, and so on until i get 10 (or until
there are no more routers - obviusly i cant get 10 if in the
db there are just 7). Now this is a really simple scenario,
but you can imagine one user specifing several desired
characteristics.
I tought about recursive use of business rules, i mean i
look first for routers with X ports, then X+1 or X-1 ports,
then X-2 or X+2 ports etc. but this would lead to a monster
number of business rules, since the characteristics are
many. Moreover, this works fine with characteristics that
takes on numeric values, but what about those which takes on
Strings? I.E. encription support can be AES, DES, 3DES etc.
In this case I should specify one rule for each desired
request and for each step, i.e. if the user wants AES
support then look for AES first, then 3DES, then DES etc. OR
if he wants 3DES then 3DES first, then AES etc. (just a dumb
example but i hope you get the point).
I see this is quite a lot of rules handling.. maybe someone
has a suggestion for another approach which would simplify
the process? Or maybe someone had to solve something similar
and would share some knowledge with me?
Thanks for the attention :)
Cheers
Alessandro Terrinoni
_________________________________________________________________
Scopri le keyword più cercate della settimana!
http://clk.atdmt.com/GBL/go/136430524/direct/01/_________________________...
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users