Okay .. That brings up another question
though, performance / memory wise what’s better –
to load all the DDR Ram options in memory
during initialization and work through memory ?
OR pulling them up from database with
every call
OR pulling them up from database on first
call and then putting them into memory and work through memory thereafter?
-abhay
==================================
From:
rules-users-bounces@lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Wendy Mungovan
Sent: Friday, May 06, 2011 5:47 PM
To: Rules Users List
Subject: Re: [rules-users] Basic
rules question
Q2:
So the rule would be something like:
rule "RAM type"
when
$product: Product(type == "laptop");
then
//you are looking for the best way to set valid RAM
types in the then part of the rule?
$product.setRamType("DDR");
//or
$product.setValidRamOptions( getValidRamOptions("DDR"));
end
where getValidRamOptions would be a custom function included through 'import
function' so you can then load the choices from some where else. Or if
RamOptions were an object in memory you could have a rule like:
rule "RAM type"
when
$product: Product(type == "laptop");
$ramOptions: RAMOptions(type == "DDR");
then
$product.setValidRamOptions( $ramOptions.getList());
end
Wendy
==================================
Regards,
Abhay Chaware
Sr. Designer | KPIT Cummins Infosystems Ltd
| Board: +91 020 6652 5000 | Extn: 2989 | abhay.chaware@kpitcummins.com
|www.kpitcummins.com
P Please consider the environment before printing this e-mail
From:
rules-users-bounces@lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Wendy Mungovan
Sent: Friday, May 06, 2011 5:47 PM
To: Rules Users List
Subject: Re: [rules-users] Basic
rules question
Abhay,
Q1: I think that this will depend on how many different products
you have. If there is a small number it is more straight forward to have
a rule for each one (so the 2nd option). This allows all you logic to be
in one place. If there are a large number of products and writing a rule
for each one is intractable you probably would want to look into some
generalizations of the rules. Is that helpful?
Q2: I'm not quite sure what you are getting at in Q2. Are you
trying to write validation rules or rules that are modifying the facts?
Wendy
From: Abhay B.
Chaware <Abhay.Chaware@kpitcummins.com>
To: "
Sent: Fri, May 6, 2011 4:59:46 AM
Subject: [rules-users] Basic rules
question
Hi
I am a newbie to rule based applications and trying to get
the concept of rules. I have couple of questions about rules to start with, not
specifically about Drools though.
Q1 - Should rules be data/model specific or can/should they
be generic or both
==========================================================
e.g.
If selected product “TYPE” is “laptop”, then category “RAM”
should have all “DDR” type items compatible ( selecting items matching certain
property )
OR
If selected product is “IBM T42”, then category “RAM” should
have “512MB DDR” , “1024MB DDR”, “2048MB DDR” compatible. ( assigning
individual items in rules )
OR
Combination of both
Q2 – How should be the data modeled in above case
==========================================================
e.g.
in product master, each item ( e.g. T40, T42 ) should have a
“TYPE” ( e.g. desktop or laptop ) , all items in category “RAM” should have a
“TYPE” ( e.g. DDR ) and then control the assignment of RAM options to the
PRODUCT through Rule using “DDR” type ?
OR
in product master, each item ( e.g. T40, T42 ) should have a
“TYPE” ( e.g. desktop or laptop ) , all items in category “RAM” should
have a “compatibleProduct” column ( e.g. desktop or laptop ) and control the
assignment of RAM to PRODUCT through “dynamic” rules by selecting all the RAMs
by passing the “TYPE” of the product to the database handler.
Am I making my point clear ?
Thanks
Abhay
This message contains information that may be privileged or confidential and is
the property of the KPIT Cummins Infosystems Ltd. It is intended only for the
person to whom it is addressed. If you are not the intended recipient, you are
not authorized to read, print, retain copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error, please
notify the sender immediately and delete all copies of this message. KPIT
Cummins Infosystems Ltd. does not accept any liability for virus infected
mails.