Re: [rules-users] Dynamic facts
On 19 July 2011 13:42, Marc Heinz marc.he...@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. 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
Re: [rules-users] Dynamic facts
Thank you for your response, Wolfgang. 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. Hum ok, the documentation stills need to be updated though... 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. Understood, I may give it another try. But in all cases, I don't feel comfortable in relying on features that are not described in the API, nor the documentation. 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. I'm not sure to fully understand this statement... If i take the following rules: = rule Single rule check age when p : Person( age 18 ) then System.out.println(Single rule fired); end rule Rule 1 of n when p : Person( name.equals(Adam) ) then System.out.println(Rule 1 of n fired); end // [...] hundred of others similar rules that will perform a check on the // name attribute. = And with the following java code: Person p = new Person(); p.setAge(22); p.setName(Adam); FactHandle fh = ksession.insert(p); ksession.fireAllRules(); p.setAge(23); ksession.update(fh, p); ksession.fireAllRules(); This will actually produce the output: Rule 1 of n fired Single rule fired Rule 1 of n fired Single rule fired 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? For example, I expect a different behavior when using a PropertyChangeSupport object that would fire events only for specific fields (but I wasn't able to test it yet)... Thanks, Marc ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Dynamic facts
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... 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). 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. Is this some current limitation of Drools? Does it have something to do with those Shadows Fact? (that would be somehow immutable?) 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). It would also means that one should always aim at the finest granularity for better performances, 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
