10:59 a.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
View this message in context:
http://www.nabble.com/Attribute-activations-vs-object-activations-tf46742...
Sent from the drools - user mailing list archive at Nabble.com.