<br><br><div class="gmail_quote">On 19 July 2011 07:07, Marc Heinz <span dir="ltr"><<a href="mailto:marc.heinz@no-log.org">marc.heinz@no-log.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello everyone,<br>
<br>
I need some enlightening about Drools "dynamic facts" (a term used in the<br>
documentation, for facts that could be updated from outside the rule<br>
engine).<br>
<br>
The current documentation always list the "insert" method of a<br>
StatefulKnowledgeSession being able to take an additional boolean<br>
argument, stating that the corresponding fact supports the<br>
PropertyChangeSupport related methods.<br>
<br>
However, it seems that this method do not exists anymore for already some<br>
time now...<br></blockquote><div><br>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.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
After googling for a while it appears that some possible workaround were<br>
modifyInsert (apparently removed from the API as well) and the<br>
@propertyChangeSupport meta-data annotation, but I didn't manage to make<br>
it work (actually I wasn't able to find any reference from it in the API,<br>
so I guess that it is also not available anymore).<br></blockquote><div><br>It should work, e.g.:<br><br> declare SomeType<br> @propertyChangeSupport(true)<br> end<br><br>Although in 5.2.0 there are some severe issues when building using a change set, which might make this "disappear".<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
So, this left us with the "session.update" method. Which seems to works<br>
great, except that it will invalidate the whole fact into the working<br>
memory, even if only some of the fields were changed.<br></blockquote><div><br>AFAIK, there never was any logic for restricting updates of the Rete structures according to individual field-oriented change notifications.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Is this some current limitation of Drools? Does it have something to do<br>
with those "Shadows Fact"? (that would be somehow immutable?)<br></blockquote><div><br>No.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
If we effectively can't fire update targeted to some specific fields, this<br>
has probably some big implications on performances (even for simple fact<br>
with only a few fields).</blockquote><div><br>No. Rete has been designed to cope with just that.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It would also means that one should always aim at<br>
the finest granularity for better performances,</blockquote><div><br>No - if I understand this correctly as being a corollary of the preceding statements.<br><br>-W <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
by somehow "flattening"<br>
the object structure into the knowledge base (which in turn could make<br>
complicated to reuse those same Pojo in other frameworks, such as<br>
hibernate).<br>
<br>
Did I miss something?<br>
<br>
Any feedback deeply appreciated,<br>
<br>
Thanks!<br>
<br>
M. H.<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</blockquote></div><br>