[rules-users] Dynamic facts

[Wolfgang Laun]

On 22 July 2011 08:34, Marc Heinz <marc.heinz at no-log.org> wrote:

> > On 19 July 2011 13:42, Marc Heinz <marc.heinz at 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:

   1. 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".
   2. 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.
   3. 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110722/6a3c2b68/attachment.html