On 19 July 2011 07:07, Marc Heinz
<marc.heinz@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users