Drools 7 and Property Reactive with Maps

742 views
Skip to first unread message

KimJohn Quinn

unread,
Jun 20, 2017, 5:34:03 AM6/20/17
to Drools Usage
We currently have a ruleset that relies heavily on Map facts.  In Drools 6.5 we fire approximately 400 rules.  

In Drools 7.0 we get only about 50 rules unless we add the "<property key="drools.propertySpecific" value="ALLOWED"/>" to the kmodule.xml, in which case we fire the full 400 rules or by using @Watch(*) or @Watch(!*) on the rules.  It "seems" like only the first evaluations of the rules are firing and then no others after that.

Our flow generally follows something like below, within a stateful session, using rules only.  We fire all rules per-request then close the session.
  1. Watch for changes to the Map properties
  2. If a certain property or properties exist a 'populate' rule fires (calls modify())
  3. The populate rule enriches the map fact. (calls modify())
  4. Based on #3, more rules fire when certain properties exist (calls modify())
We are work heavily with rules that depend on loaded available facts up-front and computed properties throughout evaluation.  

I have a couple of usage questions regarding Drools 7, the default enabling of Property Reactive and using Maps as the facts:
  • In general, how do maps work with property reactive and respond to modify/insert events?  Does Drools look at the Map as a whole, any change re-evaluates the tree, or each individual property within the map re-evaluates the change?

  • In Drools 7, by defaulting the property reactive setting, does that mean all rules need to be annotated or they should they work as is (dao or map-based facts) when using modify/insert?


Mario Fusco

unread,
Jun 20, 2017, 12:05:14 PM6/20/17
to Drools Usage
Hi,

as you find in our documentation, in drools 7 we enabled property reactivity by default. I think that in general this has been an important improvement but given your description it seems that it isn't playing well with Maps. I believe that what it is happening in your case is that property reactivity sees the Map as a whole so if you change one of its entry the property reactivity blocks the propagation of this modification through the engine. You can workaround this problem but either annotating the patterns matching against the Maps or disabling property reactivity, but I understand that none of this solution is ideal.

I believe we can improve the current situation and let property reactivity to work also with Maps. In order to help me to further investigate this issue it would be great if you could open a ticket on our jira and attach there a minimal reproducer with one or two rule modifying a single map.

Thanks a lot for your collaboration,
Mario


--
You received this message because you are subscribed to the Google Groups "Drools Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage+unsubscribe@googlegroups.com.
To post to this group, send email to drools...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/1260c1c3-1199-4067-b815-84ac17fa98a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mark Proctor

unread,
Jun 20, 2017, 3:48:19 PM6/20/17
to drools...@googlegroups.com, davide sottara
it should be possibly to apply a trait to a map (i think) and from there property reactive should work.

mark

To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage...@googlegroups.com.

To post to this group, send email to drools...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/1260c1c3-1199-4067-b815-84ac17fa98a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Drools Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage...@googlegroups.com.

To post to this group, send email to drools...@googlegroups.com.

Mark Proctor

unread,
Jun 20, 2017, 4:31:24 PM6/20/17
to drools...@googlegroups.com
We have some experimental work to trait maps, turning them into type safe instances that should work with property reactive.

Mark

Davide Sottara

unread,
Jun 20, 2017, 7:27:20 PM6/20/17
to drools...@googlegroups.com
Yes,
the 'trait' interface turns key strings into type-safe properties. In fact, the trait interface properties are bound to the key-value pairs in the map, rather than to a getter/setter pair in an underlying bean
However, since patterns can use actual POJO beans or trait interfaces in the exact same way, property reactivity will work (or at least it should - please let us know if it does not) 

Btw, you can still access any additional key-value pairs in a non-type safe manner even from the trait interface 

KimJohn Quinn

unread,
Jul 5, 2017, 8:04:56 AM7/5/17
to Drools Usage
These traits are ridiculously cool and work well when transforming maps to a more type-safe fact.

Three questions:
  1. How "experimental" is experimental with them?  Referencing the doco.
  2. Is "don" the equivalent of insertLogical or insert?
  3. Is it a good practice, or case-by-case, to insert the model that backs the trait or is it fine just to don the trait?
Thanks.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage...@googlegroups.com.

To post to this group, send email to drools...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/1260c1c3-1199-4067-b815-84ac17fa98a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Drools Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage...@googlegroups.com.

To post to this group, send email to drools...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Drools Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage...@googlegroups.com.

To post to this group, send email to drools...@googlegroups.com.

Mark Proctor

unread,
Jul 5, 2017, 9:30:07 AM7/5/17
to drools...@googlegroups.com, davide sottara
On Wed, Jul 5, 2017 at 1:04 PM, KimJohn Quinn <k...@logicdrop.com> wrote:
These traits are ridiculously cool and work well when transforming maps to a more type-safe fact.

Three questions:
  1. How "experimental" is experimental with them?  Referencing the doco.
It just means we want freedom to work on and improve them, potentially with API changes. It's  not a high priority task right now, so that tends to drag on, as we are struggling to find time to progress this.

Next stages are to integrate this with a TripleStore and to find someway to start to introduce semantic ontologies with this work into drools.
  1. Is "don" the equivalent of insertLogical or insert?
No, A "don" can be logically applied, and thus unapplied - but it doesn't have to be it can be a stated don too (I think). All a don does is inject an interface for a given instance. 
  1. Is it a good practice, or case-by-case, to insert the model that backs the trait or is it fine just to don the trait?
not sure what you mean.

Mark 
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage+unsubscribe@googlegroups.com.

To post to this group, send email to drools...@googlegroups.com.

Davide Sottara

unread,
Jul 5, 2017, 9:41:21 AM7/5/17
to drools...@googlegroups.com
On Wed, Jul 5, 2017 at 7:04 AM, KimJohn Quinn <k...@logicdrop.com> wrote:
These traits are ridiculously cool and work well when transforming maps to a more type-safe fact.
Thanks! 
 
Three questions:
  1. How "experimental" is experimental with them?  Referencing the doco.
I'll defer to Mark re what gets flagged as 'experimental' and when and why
From a technical perspective, the core of the capability is fairly mature, but there are side features that are still being studied and experimented with. 
  1. Is "don" the equivalent of insertLogical or insert?
No, it is its own WM operation. It triggers the generation of the wrappers that adapt the objects to the trait interfaces. There is a 'logical' version of don, too  
  1. Is it a good practice, or case-by-case, to insert the model that backs the trait or is it fine just to don the trait?
The model is inserted automatically as part of the donning. The engine is expected to take care of the consistency of the WM
 
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage+unsubscribe@googlegroups.com.

To post to this group, send email to drools...@googlegroups.com.

KimJohn Quinn

unread,
Jul 9, 2017, 11:01:07 AM7/9/17
to Drools Usage
Reply all
Reply to author
Forward
0 new messages