[rules-users] Dynamic facts

[Wolfgang Laun]

On 19 July 2011 07:07, Marc Heinz <marc.heinz at no-log.org> wrote:

> Hello everyone,
>
> I need some enlightening about Drools "dynamic facts" (a term used in the
> documentation, for facts that could be updated from outside the rule
> engine).
>
> The current documentation always list the "insert" method of a
> StatefulKnowledgeSession being able to take an additional boolean
> argument, stating that the corresponding fact supports the
> PropertyChangeSupport related methods.
>
> However, it seems that this method do not exists anymore for already some
> time now...
>

It's still there in KnowledgeHelper - not in the "stable" part of the API,
though. But using this method is not a good choice, IMHO.


> After googling for a while it appears that some possible workaround were
> modifyInsert (apparently removed from the API as well) and the
> @propertyChangeSupport meta-data annotation, but I didn't manage to make
> it work (actually I wasn't able to find any reference from it in the API,
> so I guess that it is also not available anymore).
>

It should work, e.g.:

  declare SomeType
    @propertyChangeSupport(true)
  end

Although in 5.2.0 there are some severe issues when building using a change
set, which might make this "disappear".


>
> So, this left us with the "session.update" method. Which seems to works
> great, except that it will invalidate the whole fact into the working
> memory, even if only some of the fields were changed.
>

AFAIK, there never was any logic for restricting updates of the Rete
structures according to individual field-oriented change notifications.


>
> Is this some current limitation of Drools? Does it have something to do
> with those "Shadows Fact"? (that would be somehow immutable?)
>

No.


>
> If we effectively can't fire update targeted to some specific fields, this
> has probably some big implications on performances (even for simple fact
> with only a few fields).


No. Rete has been designed to cope with just that.



> It would also means that one should always aim at
> the finest granularity for better performances,


No - if I understand this correctly as being a corollary of the preceding
statements.

-W

by somehow "flattening"
> the object structure into the knowledge base (which in turn could make
> complicated to reuse those same Pojo in other frameworks, such as
> hibernate).
>
> Did I miss something?
>
> Any feedback deeply appreciated,
>
> Thanks!
>
> M. H.
> _______________________________________________
> 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/20110719/04b21e58/attachment.html