Drools 5 - Not sure why this simple DSL not working
by Vijay K Pandey
Hi,
I am trying to get a very simple DSL working but all the time it gives the error of Unable to expand: If I take the DSL away everything runs fine, not sure whats going on.
So what I did is strip away all other stuff and just added a plain simple DSL -- but still the same error
Unable to expand: LOGGING
DSLR file Contents:
package test.rules
dialect "mvel"
expander testing.dsl
rule "TestingCheck"
when
then
LOGGING
end
DSL file content
[consequence][]LOGGING=System.out.println("hello");
ChangeSet XML file (test_changeset.xml)
<change-set xmlns='http://drools.org/drools-5.0/change-set'
xmlns:xs='http://www.w3.org/2001/XMLSchema-instance'
xs:schemaLocation='http://drools.org/drools-5.0/change-set drools-change-set-5.0.xsd' >
<add>
<resource source='classpath:test/rules/test.drl' type='DSLR' />
<resource source='classpath:test/rules/testing.dsl' type='DSL' />
</add>
</change-set>
I am loading the changeset set via
KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
kbuilder.add(ResourceFactory.newClassPathResource("test_changeset.xml"), ResourceType.CHANGE_SET);
Any hint what is going wrong?
Thanks
Vijay
16 years, 1 month
Re: [rules-users] Using multiple threads for parallel rule flow execution
by Tobias Buchloh
Hi Edson,
thank you very much for your answer.
> If it is LHS of the rules that is taking too long to execute, then you
> may try enabling the engine multi-thread evaluation option.
Well, it is the LHS which we would like to speed up because we
anticipate a few hundred rules in there and only a few in the RHS. We
are just building a proof of concept so we don't know if we will need it
later in production. We want to make sure we will have this option, just
in case.
So we would like to enable the engines multi-threading evaluation. Do
you have a link with some documentation? I didn't find anything to this
topic on jboss.com and google.
Thank you!
Cheery,
Tobias
16 years, 1 month
Why is a flat object recommended?
by Christie, Blair
In the documents this is dicussed briefly:
"). Object models can often have complex relationships and hierarchies
in them - for rules you will want to simplify and flatten the model
where possible, and let the rule engine infer relationships (as it
provides future flexibility."
What does it mean that the rule engine can infer relationships?
Are there performance reasons for having a flat model?
Cheers,
Blair
16 years, 1 month
Re: [rules-users] Why is a flat object recommended?
by Greg Barton
I would hesitate using "from" for accessing nested structures for performance reasons. See the attached project:
$ java -jar target/DroolsNestedTest-1.0.jar from.drl
Time: 980ms
BAR Duplicates: 58
FOO Duplicates: 38
$ java -jar target/DroolsNestedTest-1.0.jar reference.drl
Time: 36ms
BAR Duplicates: 48
FOO Duplicates: 38
Note the 27x performance difference. :)
In this case it's because I used two "from" statements in a rule, but this is a pretty common occurrence. Just try upping the COUNT parameter in DroolsTest. Prepare to wait a while for the from.drl to finish. The reference.drl does just fine.
So, to help out your business users, you might dry a domain specific language. You can generate the nested reference == just as easily as a "from" expression.
--- On Thu, 8/13/09, Libor Nenadál <libor.nenadal(a)gmail.com> wrote:
> From: Libor Nenadál <libor.nenadal(a)gmail.com>
> Subject: Re: [rules-users] Why is a flat object recommended?
> To: rules-users(a)lists.jboss.org
> Date: Thursday, August 13, 2009, 9:56 AM
>
>
> Mark Proctor wrote:
> >
> > We can exploit cartesian products and indexing for ==
> constraints. If
> > its a nested model we have to iterate over all
> possible instances. The
> > other problem is if the nested model changes the
> engine has no idea this
> > has happened, which if you are not careful can lead to
> data integrity
> > issues.
> >
> I think that plain flat model is too limited for real life.
> In fact in most
> situations you just cannot avoid nesting.
> For example when I try to search for cars with 4 cylinder
> engine the best
> approach I found is:
>
> rule "get 4 cylinder cars"
> when
> Car ( $e: engine != null ) // car without
> engine? where are we? :)
> Engine ( cylinderCount == 4 ) from $e
> then
> System.out.println("Found 4 cylinder car.");
> end
>
> This should be quite effective. I doubt that the following
> solution with
> cartesian product has the same complexity:
>
> rule "get 4 cylinder cars"
> when
> $e: Engine ( cylinderCount == 4 )
> Car ( engine == $e )
> then
> System.out.println("Found 4 cylinder car.");
> end
>
> Using approach Car ( engine.cylinderCount == 4 ) tends to
> raise
> NullPointerException and I had problems with assigning the
> cylinderCount to
> variable so this was not a way to go for me.
>
> But this is not much a problem for me as I am a programmer
> and I can
> understand the rule language and data structures. But when
> business users
> are to edit rules (using Guvnor as the tool of choice) we
> come to troubles.
> I think that guided editor for rules does not allow "from".
> More importantly
> - can you create such a structure for a test scenario? I
> failed. :(
> --
> View this message in context: http://www.nabble.com/Why-is-a-flat--object-recommended--tp15567690p24954...
> Sent from the drools - user mailing list archive at
> Nabble.com.
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
16 years, 1 month
Re: [rules-users] Drools and Clojure
by Greg Barton
Well, you never know it performs until you try. :) See attached project.
$ java -jar target/DroolsMapTest-1.0.jar eval.drl
{bar=0}
{foo=1000000}
Time: 6607ms
$ java -jar target/DroolsMapTest-1.0.jar mvel.drl
{bar=0}
{foo=1000000}
Time: 13077ms
So eval ended up being 2x as fast, at least for this micro benchmark. I guess the fact that the "this['foo']" expressions are not indexed, plus the fact that they're interpreted mvel, doubles up. Stick with the eval.
--- On Thu, 8/13/09, André Thieme <address.good.until.2009.dec.14(a)justmail.de> wrote:
> From: André Thieme <address.good.until.2009.dec.14(a)justmail.de>
> Subject: Re: [rules-users] Drools and Clojure
> To: "Rules Users List" <rules-users(a)lists.jboss.org>
> Date: Thursday, August 13, 2009, 6:29 PM
> With what have you been wrong Greg?
> I understood Marks reply in such a way that the mvel
> dialect allows to
> use Maps without eval. But this is just syntactic sugar.
> When compiled
> or interpreted (I don't know which of those Drools will do
> with mvel
> rules), this will get replaced with an eval under the
> hood.
> So, that means that still the optimizations can't be
> applied.
> Maybe the mvel rule is only interpreted, which would make
> it even slower.
>
> For me it does not matter much which syntax will be my
> target.
> My Clojure lib will allow to write down rules in
> s-expression
> syntax, and it will compile them (compilation is also
> available at
> runtime) into any syntax Drools accepts.
> Currently my target is the default syntax - that means I
> will
> produce strings that access Maps with eval.
>
> IF the mvel syntax will result in more performant code
> because it
> makes Drools handle it better without using eval under the
> hood, then
> sure, I can also compile into mvel syntax.
> Although with that I still have the little problem to have
> globals in
> place of literals for Map lookups (see my other mail).
>
>
>
> Greg Barton schrieb:
> > I was wrong. :). See Mark's later email.
> >
> > GreG
> >
> > On Aug 13, 2009, at 17:25, André Thieme <address.good.until.2009.dec.14(a)justmail.de>
> wrote:
> >
> > Greg Barton schrieb:
> > There's no reason why a rete based system couldn't use
> maps as first
> > class objects, but Drools is heavily oriented towards
> POJOS. Using
> > eval in the way you have is pretty much the way to
> go.
> >
> > Thanks for confirming that.
> > For now I know that I am doing it right by using eval
> and that this
> > means that rules for typical Clojure objects will not
> benefit from some
> > of the optimizations Drools usually can apply.
> > Maybe it will change in the future.
> >
> >
> > As long as type information is accessible (both for
> first class types
> > and their members) you should be able to have the left
> hand side of a
> > rule (the conditions) be as it is now.
> >
> > I think that if Maps become 1st class objects there
> could be a different
> > Syntax, without using eval.
> >
> >
> > If you lobby the devs hard enough and get others on
> your side you may
> > be able to convince them to go in that direction, but
> I doubt it
> > would be possible before version 6 or so, if that
> early. (And I'm
> > not even sure it's possible.)
> >
> > At this point it is mostly interesting for me to get
> Drools working with
> > Clojure together and concentrate on correctness. The
> goal is that users
> > of my lib can use do all typical things people do with
> Drools without
> > writing Java code. Everything, including the rules,
> would be written in
> > Clojure.
> > But of course it would be very interesting if the devs
> could indeed have
> > Clojure in mind. I don't know how reusable the
> existing code is, for
> > using Maps without the need for eval and with having
> the respective
> > performance advantages.
> > I understand that the looup of the value for a given
> key can not be
> > optimized away. On my hardware get() is limited to
> "only" 1000 calls
> > per msec and core. Reading a field from a POJO is
> faster.
> > If I understand it correctly then the "problem" with
> eval is that it
> > needs to be executed each time, and no clever caching
> can be done.
> > So, eliminating that by having Maps being 1st class is
> what sounds
> > interesting.
> > When I refer to Maps and Clojure, then I talk about
> Maps having only
> > very few key/value pairs, just like POJOs, and being
> immutable.
> > This immutability may even be very helpful for
> optimization. It is
> > guaranteed that a given object will never change.
> >
> > I hope the devs will find it okay if I make some
> concrete suggestions
> > in the coming weeks.
> >
> >
> > Sunny greetings,
> > André
>
>
> --
> Lisp is not dead. It’s just the URL that has changed:
> http://clojure.org/
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
16 years, 1 month
how to convert drl to dsl
by drools
hi all, can any one help me how can convert drl to dsl for drools,let say for
the following code what will be the dsl,
rule 'Rank accomodation name'
salience 90
when
$accBase: AccomodationBase()
not AccomodationBase( eval( $accBase instanceof AccomodationRank) )
$accRank: AccomodationRank( level == $accBase.level, description ==
$accBase.description )
then
$accRank.setScore($accRank.getScore()+1);
end
thanks
--
View this message in context: http://www.nabble.com/how-to-convert-drl-to-dsl-tp24955345p24955345.html
Sent from the drools - user mailing list archive at Nabble.com.
16 years, 1 month
Re: [rules-users] Drools and Clojure
by Greg Barton
I was wrong. :). See Mark's later email.
GreG
On Aug 13, 2009, at 17:25, André Thieme <address.good.until.2009.dec.14(a)justmail.de> wrote:
Greg Barton schrieb:
There's no reason why a rete based system couldn't use maps as first
class objects, but Drools is heavily oriented towards POJOS. Using
eval in the way you have is pretty much the way to go.
Thanks for confirming that.
For now I know that I am doing it right by using eval and that this
means that rules for typical Clojure objects will not benefit from some
of the optimizations Drools usually can apply.
Maybe it will change in the future.
As long as type information is accessible (both for first class types
and their members) you should be able to have the left hand side of a
rule (the conditions) be as it is now.
I think that if Maps become 1st class objects there could be a different
Syntax, without using eval.
If you lobby the devs hard enough and get others on your side you may
be able to convince them to go in that direction, but I doubt it
would be possible before version 6 or so, if that early. (And I'm
not even sure it's possible.)
At this point it is mostly interesting for me to get Drools working with
Clojure together and concentrate on correctness. The goal is that users
of my lib can use do all typical things people do with Drools without
writing Java code. Everything, including the rules, would be written in
Clojure.
But of course it would be very interesting if the devs could indeed have
Clojure in mind. I don't know how reusable the existing code is, for
using Maps without the need for eval and with having the respective
performance advantages.
I understand that the looup of the value for a given key can not be
optimized away. On my hardware get() is limited to "only" 1000 calls
per msec and core. Reading a field from a POJO is faster.
If I understand it correctly then the "problem" with eval is that it
needs to be executed each time, and no clever caching can be done.
So, eliminating that by having Maps being 1st class is what sounds
interesting.
When I refer to Maps and Clojure, then I talk about Maps having only
very few key/value pairs, just like POJOs, and being immutable.
This immutability may even be very helpful for optimization. It is
guaranteed that a given object will never change.
I hope the devs will find it okay if I make some concrete suggestions
in the coming weeks.
Sunny greetings,
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
16 years, 1 month
Type declaration in DSL
by Chandana Pingle
hi all,
I have recently started using Drools 5.0 .I have a difficulty in
writing the expressions in DSL file.i have my .dslr file written like
this
when
>not PricingResult()
>productType : ProductType()
>customer : Party()
then
create a PricingResult
set productType
set customer
now, i am able to fire the rule successfully,with the following in
.dslr file with rule language mappings set to
pricingResult.setProductType(productType);
pricingResult.setCustomer(customer);
where productType and customer are set using CommandFactory.insert(....)
but
i want to remove the below 2 lines from .dslr file and expand them in .dsl file
productType : ProductType()
customer : Party()
how do i declare these types in DSL?
Any help would be great.
Thanks
chandana
16 years, 1 month
Using multiple threads for parallel rule flow execution
by Tobias Buchloh
Hi *,
I need to speed up the total processing time needed for the execution of
a rule flow which consists of multiple rule flow groups (e. g. A, B and
C). I'm thinking about to parallelize the execution of A and B.
+--> A --> +
Start --> split + +--> join --> C --> End
+--> B --> +
Is it possible to split a flow in multiple parallel execution paths
(with AND), execute them with real parallelism in their own threads and
join them together at the end?
Or is everything in the drools flow some sort of "pseudo-parallelism" so
that I would have to implement this by hand?
Cheers,
Tobias
16 years, 1 month
