Probably I misinterpreted you. :)
You are saying you want the ability to change the templates in order
to generate different rules? If so, probably better to keep template
based generating DRL.
I thought you would have a GUI application for the user to define
your rules with pre-defined templates... in that case, using descriptors
would sabe you the parsing time.
But not really a big difference. So, go with templates and use the
parser. No problem in doing that.
[]s
Edson
Olenin, Vladimir (MOH) wrote:
I see. The problem though is the logic and 'rule composition' is different
for each group of rules and is NOT data driven (client doesn't want the
logic to be present in the input data). From what I understand generating
descriptors directly would make me define the logic inside the 'parser' or
at the very least somewhere in Java code, unless I opt out for a separate
text format to describe 'just' the logic. But it seems like it'd be more
complicated than generating drl file directly...
Thanks for the suggestion though - I'll think it over again - probably I've
just misinterpreted you...
Vlad
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Edson Tirelli
Sent: 21 March 2007 19:17
To: Rules Users List
Subject: Re: [rules-users] field binding performance implications
Vlad,
Looking at the macro steps, when you load and run rules in the
engine, that is what happens:
* PARSING: a parser, will parse whatever syntax you are using into an
AST tree. The objects that compound that tree are the descriptors I'm
talking about.
* BUILDING: a rule builder will transform your descriptors (AST Tree)
into the internal rules representation, doing all the code generation
and compiling it into binary form.
* RETE-BUILDING: a ReteOO builder will get your compiled rules
representation and transform into a Rete network, making it ready for
execution
So, basically, descriptors are the result of the parsing. If you are
generating rules, better to skip the parsing phase and generate
descriptors directly. Also, we aim to have full round-trip between
supported semantics. That means that from the descriptors, you can
generate DRL, XML, CLP, or whatever syntax you have a dumper for.
Having said all that, you can find the descriptors in the package:
org.drools.lang.descr in the drools-compiler project. Documentation is
not good (any volunteers? :)), but they are pretty simple to use, so you
will have no problems understanding them. Also, if you don't know how to
represent something using descriptors, it is easy to find out. Just
write a DRL that does what you want to know how and use the package
builder to get the descriptors for you to see:
DrlParser parser = new DrlParser();
final PackageDescr pkgDescr = parser.parse( new
InputStreamReader( getClass().getResourceAsStream( "test_rules.drl" ) ) );
Hope it helps.
[]s
Edson
Olenin, Vladimir (MOH) wrote:
Hmm... Descriptors? What is this?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Edson Tirelli
Sent: 21 March 2007 16:47
To: Rules Users List
Subject: Re: [rules-users] field binding performance implications
Vlad,
Didn't tested myself, but I don't see a reason for performance impacts
adding unneeded declarations, except for consuming a bit more of memory,
but I would say would be negligible in the numbers you provided.
Although, may I suggest that you generate Descriptors instead of DRL?
This will give you gains in parsing time (as there will not be parsing),
besides being easier than using string templates IMO. Also, if you want
to store a "text" based version of your rules, you can simply use a
dumper to dump wherever syntax you prefer.
[]s
Edson
Olenin, Vladimir (MOH) wrote:
Hi,
We need to generate drl file from a template. Since the format of the
rules parameters doesn't fall very well within decision table concept
(the parameters are not 'homogeneous', so each row in the input excel
table can mean different things), we decided to define the rules by
automatically generating drl files from a set of templates. To cover
more cases with a single template we'd need to bind every field of
column by default, even if the binding would not be used.
For example (Freemarker syntax is used in the template below):
Rule ${ruleId}
When
Record ( $account : account ${operation} ${value} )
....
Then
.....
End
In the example above, 'operation', 'value' and 'ruleId' are objects in
the data model that we merge with the template. One case of the rule
would be when both 'operation' and 'value' are empty strings. This
will result in this LHS: Record ( $account : account ). Another case
might be when 'operation' is '==' string and 'value' is '1': Record (
$account : account == 1 ).
The above is a simplified template to demonstrate the point. The real
business data model for facts (Record object) would have around 10
fields and we can have ~ 5 to 10 columns per rule. I wonder what kind
of performance implications does field binding bring? Are there any or
this is being optimized / filtered out by some preprocessor?
In other words, is there significant difference in performance for the
following LHS expressions:
1) Record ( $account : account, $name : name == 'xxx', $balance :
balance > 100, ....)
Vs
2) Record (name == 'xxx', balance > 100, ....)
Providing the functionality of both of these LHS expressions is the
same and field bindings in LHS #1 are never used throughout the rule.
Thanks,
Vlad
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
