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