Re: [rules-users] Attribute activations vs object activations

2007-10-23 Thread Joshua Undesser

Mark,

Thank you for the quick response.I understand what you are saying in
terms of efficiency, the problem we have though is that the rule engine is
only one of many client applications to our system, and in terms of
injecting data into our system it is actually a very minor client at that.   
It is really the other clients that are doing the majority (95%) of the
creating, modifying, and deleting.   The rule engine we have set up is more
of a cautionary client that creates Alert objects to notify the users, using
other clients to our system, that something is wrong.   IE don't put a fox
in the same room as a chicken without a person, those types of things (but
obviously more complex than this).   As such, and since we are adhering to
the java bean event model, all modifications that come to our Drools client
are in the form of single value property change events.   That is why I was
using the dynamic ones.   Figured it was the same as me calling update after
every single update anyway.   What I could do though is set up a queue on my
Drools engine client that will store the external incoming property change
events and batch process them say every 2-5 seconds.   

I can see what you are saying though for batch commands, especially if the
right hand side of the rule is creating/modifying tons of objects (internal
drools events).In that case it would be most beneficial to do batch
processing because you are in control of the events.

Also thank you for the heads up on the slot-specific rule activations
functionality.I think this will definitely be a nice addition to the
Drools engine and I look forward to it's release! 

Thanks again!  

Joshua
  







Mark Proctor wrote:
 
 firstly I wouldn't recommend you use the dynamic update stuff its not 
 very efficient. its no less efficient than jess, but the principle 
 itslef is bad. The reason is because each field change results in a 
 notification to the engine, where as you really want to notify the 
 engine after a batch of changes to the instance.
 
 The feature I believe you are after is called slot-specific, so that 
 only fields which are constrained on pick up the notifications if those 
 fields have changed. This is not currently supported - sorry. Will 
 probably be in our next major release in Q1.
 
 Mark
 
 Joshua Undesser wrote:
 I am sorry if this has already been answered, I tried a few different 
 search
 combinations within this user forum and didn't find an answer.

 I am pretty new to Drools, but am no stranger to JESS and CLIPS.   We are
 currently looking at moving over our product implementations from JESS to
 DROOLS.   In looking at what it will take to do the conversion, and 
 working
 with a few sample systems, i've noticed that DROOLS doesn't seem to 
 support
 attribute activations, only object activations.What I mean by this is
 say that I have two rules.

 rule Rule 1
 when
$o : ObjectType (type == OBJECTTYPE.STATIC )
 then
System.out.println(ObjectType is Static);
 end

 rule Rule 2
 when
$o : ObjectType (active == false)
 then
System.out.println(ObjectType not active);
 end


 (My sample system is utilizing the default Drools 4.0 shadow fact 
 support so
 as an ObjectType object is created I am calling memory.insert(obj, 
 true) for
 dynamic updates.)

 If on external property change event occurs on an ObjectType:active
 attribute, both rules fire.  Which to me signifies that if any 
 attribute on
 the ObjectType object happens, all rules that contain ObjectType on 
 the LHS
 of the rule will be re-evaluated (not re-fired, but re-evaluated).  Now I
 realize these rules are simple and that I could code the rules in a 
 way to
 avoid them being fired, but non the less, they would still need to be
 evaluated to the point where the engine realizes it should run.   
 Instead,
 performance-wise, wouldn't it be more beneficial to only re-evaluate the
 rules that contain the attribute that changed that you are interested 
 in?   I.E.  In the above scenario, only RULE 2 would fire because rule 
 1 doesn't
 contain the attribute that changed.  
 The early versions of JESS did not support attribute activations (aka per
 slot activations), which was a major stumbling block.   However ever 
 since
 JESS 5.0, if I remember right, they've been included.  
 So I guess my question is, does DROOLS support attribute activations 
 and I
 am just blind?If Drools does not support this, is it scheduled to be
 supported in the future?   
 Thank you in advance!

 Joshua

 ___
 rules-users mailing list
 rules-users@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/rules-users


 
 
 ___
 rules-users mailing list
 rules-users@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/rules-users
 
 

-- 
View this message in context: 

Re: [rules-users] Attribute activations vs object activations

2007-10-22 Thread Mark Proctor
firstly I wouldn't recommend you use the dynamic update stuff its not 
very efficient. its no less efficient than jess, but the principle 
itslef is bad. The reason is because each field change results in a 
notification to the engine, where as you really want to notify the 
engine after a batch of changes to the instance.


The feature I believe you are after is called slot-specific, so that 
only fields which are constrained on pick up the notifications if those 
fields have changed. This is not currently supported - sorry. Will 
probably be in our next major release in Q1.


Mark

Joshua Undesser wrote:
I am sorry if this has already been answered, I tried a few different 
search

combinations within this user forum and didn't find an answer.

I am pretty new to Drools, but am no stranger to JESS and CLIPS.   We are
currently looking at moving over our product implementations from JESS to
DROOLS.   In looking at what it will take to do the conversion, and 
working
with a few sample systems, i've noticed that DROOLS doesn't seem to 
support

attribute activations, only object activations.What I mean by this is
say that I have two rules.

rule Rule 1
when
   $o : ObjectType (type == OBJECTTYPE.STATIC )
then
   System.out.println(ObjectType is Static);
end

rule Rule 2
when
   $o : ObjectType (active == false)
then
   System.out.println(ObjectType not active);
end


(My sample system is utilizing the default Drools 4.0 shadow fact 
support so
as an ObjectType object is created I am calling memory.insert(obj, 
true) for

dynamic updates.)

If on external property change event occurs on an ObjectType:active
attribute, both rules fire.  Which to me signifies that if any 
attribute on
the ObjectType object happens, all rules that contain ObjectType on 
the LHS

of the rule will be re-evaluated (not re-fired, but re-evaluated).  Now I
realize these rules are simple and that I could code the rules in a 
way to

avoid them being fired, but non the less, they would still need to be
evaluated to the point where the engine realizes it should run.   
Instead,

performance-wise, wouldn't it be more beneficial to only re-evaluate the
rules that contain the attribute that changed that you are interested 
in?   I.E.  In the above scenario, only RULE 2 would fire because rule 
1 doesn't
contain the attribute that changed.  
The early versions of JESS did not support attribute activations (aka per
slot activations), which was a major stumbling block.   However ever 
since
JESS 5.0, if I remember right, they've been included.  
So I guess my question is, does DROOLS support attribute activations 
and I

am just blind?If Drools does not support this, is it scheduled to be
supported in the future?   
Thank you in advance!


Joshua

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users





___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users