Re: [rules-users] Dynamic facts

2011-07-22 Thread Marc Heinz 
 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

2011-07-22 Thread Wolfgang Laun 
On 22 July 2011 08:34, Marc Heinz marc.he...@no-log.org wrote:

  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.


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
 https://lists.jboss.org/mailman/listinfo/rules-users

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Re: [rules-users] Dynamic facts

2011-07-22 Thread Swindells, Thomas 
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-boun...@lists.jboss.org 
[mailto:rules-users-boun...@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.he...@no-log.orgmailto:marc.he...@no-log.org wrote:
 On 19 July 2011 13:42, Marc Heinz 
 marc.he...@no-log.orgmailto: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.

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.orgmailto: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 
postmas...@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
**
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Re: [rules-users] Dynamic facts

2011-07-22 Thread Mark Proctor 

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-docs/html_single/index.html


   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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users




___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Re: [rules-users] Dynamic facts

2011-07-22 Thread Mark Proctor 

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-docs/html_single/index.html


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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users






___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Re: [rules-users] Dynamic facts

2011-07-22 Thread Mark Proctor 
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@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/rules-users




___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Re: [rules-users] Dynamic facts

2011-07-22 Thread Edson Tirelli 
   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 mproc...@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-docs/html_single/index.html

   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@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/rules-users




-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Re: [rules-users] Dynamic facts

2011-07-19 Thread Wolfgang Laun 
On 19 July 2011 07:07, Marc Heinz marc.he...@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

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Re: [rules-users] Dynamic facts

2011-07-19 Thread Marc Heinz 

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

Re: [rules-users] Dynamic facts

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

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Re: [rules-users] Dynamic facts

2011-07-19 Thread Vincent Legendre 

 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.

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

[rules-users] Dynamic facts

2011-07-18 Thread Marc Heinz 
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