> On 19 July 2011 13:42, Marc Heinz <marc.heinz@no-log.org> wrote:
>> So, despite I have only updated one attribute of the fact (the age of a
>> Person), all rules have been fired again, even if they had nothing to do
>> with the said attribute, which could possibly produce a huge overhead.
>>
>> I maybe misunderstood some basic concept here... But is there a way to
>> prevent that?
>>
>
> Reevaluation of all patterns referring to the type of a fact/object that
> has been changed is a fundamental principle of production rule systems.

Ok, if I have well understood, my first assumption that I was trying to
explain still holds: we should minimize dependencies between rules and
fields from a single fact in order to have a finer granularity for
updates... Which could effectively requires to dispatch a POJO internal
structure into several other facts.

I would not accept this as a design principle for Drools or similar RBS. Three
reasons:

Drools (and its likes) have been built to cope with bean style objects, as the title of the classic paper puts it: "Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem".
Splitting "natural" objects into "facets" with a small number of fields creates the necessity of adding properties for connecting these facts and using additional contstraints for combining them in rules. The cure might be worse than the (suspected) ailment.
Design should not squint at implementation issues of the underlying system; it should orientate itself on a model that represents the problem well. It could be that you haven't chosen the right platform for your application - but then you won't improve matters by jeopardizing your design.

OK, that wraps it up. I assume that you'll continue as you have indicated. It might be interesting to hear about your experiences later on...

Cheers
-W

Actually we were considering doing exactly the opposite in a first time:
using enclosing classes extensively in order to make easier to provide
some kind of structural constraint on the content of the knowledge base
(such as: each values of this set should appears at most once in the
knowledge base at any give time), but this is probably better done using
the working memory in "equality mode" with custom equals methods.

Thank you again for these precision :)

Cheers,
Marc
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users