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 <[email protected]> wrote:
> From: Alessandro Terrinoni <[email protected]>
> Subject: [rules-users] Use of Drools for a product catalog retrieval in a
> best effort fashon
> To: [email protected]
> 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
> [email protected]
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
