7:07 a.m.
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.
11:36 a.m.
On 19 July 2011 07:07, Marc Heinz <marc.heinz(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
1:42 p.m.
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
1:58 p.m.
On 19 July 2011 13:42, Marc Heinz <marc.heinz(a)no-log.org> wrote:
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?
Reevaluation of all patterns referring to the type of a fact/object that
has been changed is a fundamental principle of production rule systems.
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)...
Reaction to a property change event is just
wm.update( factHandle, object )
-W
Thanks,
Marc
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
8:34 a.m.
On 19 July 2011 13:42, Marc Heinz <marc.heinz(a)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
9:05 a.m.
On 22 July 2011 08:34, Marc Heinz <marc.heinz(a)no-log.org> wrote:
> On 19 July 2011 13:42, Marc Heinz <marc.heinz(a)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.
I would not accept this as a design principle for Drools or similar RBS.
Three
reasons:
1. Drools (and its likes) have been built to cope with bean style
objects, as the title of the classic paper puts it: "Rete: A Fast Algorithm
for the Many Pattern/Many Object Pattern Match Problem".
2. Splitting "natural" objects into "facets" with a small number
of
fields creates the necessity of adding properties for connecting these facts
and using additional contstraints for combining them in rules. The cure
might be worse than the (suspected) ailment.
3. Design should not squint at implementation issues of the underlying
system; it should orientate itself on a model that represents the problem
well. It could be that you haven't chosen the right platform for your
application - but then you won't improve matters by jeopardizing your
design.
OK, that wraps it up. I assume that you'll continue as you have indicated.
It might be interesting to hear about your experiences later on...
Cheers
-W
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:50 a.m.
My advice for designing datamodels and working with drools is to think of it as a database
and follow standard database normalization procedures.
Essentially drools in an in memory database which has a custom query and trigger syntax
implemented in a very efficient manner! Each Object type is a table and each fact is a
row in that table.
Multiple conditions on different facts are a join between the tables.
You wouldn't (generally) embed lists of addresses within the person table in the
database, instead you'd have two separate tables for them as this makes updates and
querying much more efficient.
Generally with drools the only time you should be using the 'from' keyword or
navigating through to child objects (person.homeAddress) is to write rules to extract
those objects out and insert them as actual working memory facts.
Thomas
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Wolfgang Laun
Sent: 22 July 2011 08:06
To: Rules Users List
Subject: Re: [rules-users] Dynamic facts
On 22 July 2011 08:34, Marc Heinz
<marc.heinz@no-log.org<mailto:marc.heinz@no-log.org>> wrote:
On 19 July 2011 13:42, Marc Heinz
<marc.heinz@no-log.org<mailto:marc.heinz@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.
I would not accept this as a design principle for Drools or similar RBS. Three
reasons:
1. Drools (and its likes) have been built to cope with bean style objects, as the title
of the classic paper puts it: "Rete: A Fast Algorithm for the Many Pattern/Many
Object Pattern Match Problem".
2. Splitting "natural" objects into "facets" with a small number of
fields creates the necessity of adding properties for connecting these facts and using
additional contstraints for combining them in rules. The cure might be worse than the
(suspected) ailment.
3. Design should not squint at implementation issues of the underlying system; it should
orientate itself on a model that represents the problem well. It could be that you
haven't chosen the right platform for your application - but then you won't
improve matters by jeopardizing your design.
OK, that wraps it up. I assume that you'll continue as you have indicated. It might be
interesting to hear about your experiences later on...
Cheers
-W
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<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
________________________________
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
3:17 p.m.
AFAIK, there never was any logic for restricting updates of the Rete
structures according to individual field-oriented change notifications.
As far I remember, JRules does.
And it could be great to add/restore this possibility in drools (is
there a JIRA somewhere where we can vote?).
For Marc's question, I think there could be a confusion between a
production/inference system like drools, and something that looks like a
database trigger. And yes, if you really want to detect fields changes
individually, fields must be inserted as individual objects in the WM.
6:23 p.m.
On 19/07/2011 14:17, Vincent Legendre wrote:
> AFAIK, there never was any logic for restricting updates of the
Rete
> structures according to individual field-oriented change notifications.
As far I remember, JRules does.
JRules does not do "slot specific". Jess
does and Clips will if you use
it's COOL OO extensions, i.e. it works on Clips objects, it does not
work on deftemplates. The reason is that Clips represents each "slot" in
COOL as a triple, so every field is it's own object.
And it could be great to add/restore this possibility in drools (is
there a JIRA somewhere where we can vote?).
For Marc's question, I think there could be a confusion between a
production/inference system like drools, and something that looks like a
database trigger. And yes, if you really want to detect fields changes
individually, fields must be inserted as individual objects in the WM.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:17 p.m.
On 19/07/2011 06:07, Marc Heinz 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...
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).
@propertyChangeSupport is the
correct way to use property change
listeners. It is used on type declarations. The boolean approach is
deprecated.
Personally I don't like the feature and I consider it an anti-pattern.
the reason being is every time you change a field it's going to notify
the engine causing it to evaluate that change. you change 3 fields you
end up with triple the amount of work, then if you changed the fields
and then did a single update. Inside of the engine the consequence's
modify block does exactly that. It allows you to block together 1..n
setters and notify the engine on completion.
Lookingat docs, it's in the New and Noteworthy. Seems it wasn't copied
into the main documentation though, we'll get that done:
http://docs.jboss.org/drools/release/5.2.0.Final/droolsjbpm-introduction-...
2.3.3.15. New metadata for type declarations: @propertyChangeSupport
Facts that implement support for property changes as defined in the
Javabean(tm) spec, now can be annotated so that the engine register
itself to listen for changes on fact properties. The boolean parameter
that was used in the insert() method in the Drools 4 API is deprecated
and does not exist in the drools-api module.
*Example 2.34. @propertyChangeSupport*
declare Person
@propertyChangeSupport
end
Mark
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?)
When you
notify the engine of a change, the entire fact and all it's
fields are evaluated.
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).
This is the behaviour of most rule engines. Jess recently added a
feature for this use case called "slot specific". We've discussed
designs for this in Drools and hope to add it some time in the future.
http://blog.athico.com/2010/07/slot-specific-and-refraction.html
Mark
Did I miss something?
Any feedback deeply appreciated,
Thanks!
M. H.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:22 p.m.
On 22/07/2011 17:17, Mark Proctor wrote:
On 19/07/2011 06:07, Marc Heinz 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...
>
> 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).
@propertyChangeSupport is the correct way to use property change
listeners. It is used on type declarations. The boolean approach is
deprecated.
Personally I don't like the feature and I consider it an anti-pattern.
the reason being is every time you change a field it's going to notify
the engine causing it to evaluate that change. you change 3 fields you
end up with triple the amount of work, then if you changed the fields
and then did a single update. Inside of the engine the consequence's
modify block does exactly that. It allows you to block together 1..n
setters and notify the engine on completion.
Lookingat docs, it's in the New and Noteworthy. Seems it wasn't copied
into the main documentation though, we'll get that done:
http://docs.jboss.org/drools/release/5.2.0.Final/droolsjbpm-introduction-...
2.3.3.15. New metadata for type declarations:
@propertyChangeSupport
Facts that implement support for property changes as defined in the
Javabean(tm) spec, now can be annotated so that the engine register
itself to listen for changes on fact properties. The boolean parameter
that was used in the insert() method in the Drools 4 API is deprecated
and does not exist in the drools-api module.
*Example 2.34. @propertyChangeSupport*
declare Person
@propertyChangeSupport
end
Mark
> 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?)
When you notify the engine of a change, the entire fact and all it's
fields are evaluated.
> 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).
This is the behaviour of most rule engines. Jess recently added a
feature for this use case called "slot specific". We've discussed
designs for this in Drools and hope to add it some time in the future.
http://blog.athico.com/2010/07/slot-specific-and-refraction.html
Although I would
add that "slot specific" is not anythign to do with
performance, if anything it may be slower as it requires management over
head. "slot specific" is about avoid loops and listening to specific
field changes. As wolfgang said, i'd avoid eager optimisation of your
model for performance reasons only. First ascertain you have an issue
and then take a step back and try and decide the best way to solve it.
Mark
Mark
> Did I miss something?
>
> Any feedback deeply appreciated,
>
> Thanks!
>
> M. H.
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:17 p.m.
Ok,
I added documentation for this and all other predefined type and field
annotations to the main drools expert document.
Edson
2011/7/22 Mark Proctor <mproctor(a)codehaus.org>
On 19/07/2011 06:07, Marc Heinz 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...
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).
@propertyChangeSupport is the correct way to use property change
listeners. It is used on type declarations. The boolean approach is
deprecated.
Personally I don't like the feature and I consider it an anti-pattern. the
reason being is every time you change a field it's going to notify the
engine causing it to evaluate that change. you change 3 fields you end up
with triple the amount of work, then if you changed the fields and then did
a single update. Inside of the engine the consequence's modify block does
exactly that. It allows you to block together 1..n setters and notify the
engine on completion.
Lookingat docs, it's in the New and Noteworthy. Seems it wasn't copied into
the main documentation though, we'll get that done:
http://docs.jboss.org/drools/release/5.2.0.Final/droolsjbpm-introduction-...
2.3.3.15. New metadata for type declarations: @propertyChangeSupport
Facts that implement support for property changes as defined in the
Javabean(tm) spec, now can be annotated so that the engine register itself
to listen for changes on fact properties. The boolean parameter that was
used in the insert() method in the Drools 4 API is deprecated and does not
exist in the drools-api module.
*Example 2.34. @propertyChangeSupport*
declare Person
@propertyChangeSupport
end
Mark
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?)
When you notify the engine of a change, the entire fact and all it's
fields are evaluated.
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).
This is the behaviour of most rule engines. Jess recently added a feature
for this use case called "slot specific". We've discussed designs for this
in Drools and hope to add it some time in the future.
http://blog.athico.com/2010/07/slot-specific-and-refraction.html
Mark
Did I miss something?
Any feedback deeply appreciated,
Thanks!
M. H.
_______________________________________________
rules-users mailing
listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
4655
days inactive
4658
days old
11 comments
6 participants
participants (6)
-
Edson Tirelli -
Marc Heinz -
Mark Proctor -
Swindells, Thomas -
Vincent Legendre -
Wolfgang Laun