[rules-users] DROOLs 'Guarded entry/block' tactics for Rules synchronization and ordinality?

[Wolfgang Laun]

Whenever you have a LHS with a pattern
   SomeType(...)
this results in any fact in working memory of this type being bound to
this pattern, and the rule
fires for any binding, i.e., once for each fact of type SomeType. If you
have
   SomeType(...)
   SomeType(...)
it will bind a single fact in working memory to both patterns, but as
soon as you have
more than one fact, it will bind all possible combinations. For two
facts, you'll have
(#1,#1), (#1,#2), (#2,#1) and (#2,#2).

-W

On 1 December 2012 19:20, Cotton, Ben <Ben.Cotton at morganstanley.com> wrote:
> Ø  Why not a single Pattern?
>
> Ø      fact:InsertedFactPOJO(countdownLatch == 0) If (and only if) there is
> not more than a single InsertedFactPOJO in WM it doesn't matter (except
> confuse readers) but otherwise it produces more or less disturbing effects.
>
>
>
> Interesting.  For my case (luckily?)  I have a flow of control that
> definitely only includes a single InsertedFactPOJO in WM.
>
>
>
> Where can I best isolate my Drools readings, sample exercises et. al. Drools
> discovery efforts so that I can (some day) competently answer your question
> “Why not a single pattern?”  …. Is there a place in the Drools literature
> that explicitly addresses these “disturbing effects”?
>
>
>
> THANKS WOLFGANG!
>
> …
>
>
>
> -----Original Message-----
> From: rules-users-bounces at lists.jboss.org
> [mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Wolfgang Laun
> Sent: Friday, November 30, 2012 2:22 AM
> To: Rules Users List
> Subject: Re: [rules-users] DROOLs 'Guarded entry/block' tactics for Rules
> synchronization and ordinality?
>
>
>
> On 30/11/2012, Greg Barton <greg_barton at yahoo.com> wrote:
>
>> Not a problem.  Actually I prefer to perform flow control using
>
>> working memory objects like that instead of using the keywords, but I'm
>> old school.
>
>> :)
>
>>
>
>> GreG
>
>
>
> Agenda groups provide a mechanism that's difficult to emulate using "guard
> objects", i.e., the stack-ish behaviour, with automatic return to the
> previously active group once all activations of the current group are
> exhausted.
>
>
>
>>> From: "Cotton, Ben" <Ben.Cotton at morganstanley.com>
>
>>>
>
>>> I now want to (competently!) use DROOLs language tactics that give me
>
>>> ever finer grained control over managing rule set firing behavior on
>
>>> Fact mutation events.  Specifically, I want to be able to implement
>
>>> some form of ‘Guarded entry/block’ controls.
>
>
>
> There may be some good reason for "fine grained control" every now and then,
> but basically this contravenes the fundamental idea of rules being perfectly
> capable of determining the right order - if written correctly, that is, by
> judiciously selecting fact properties by constraints.
>
>
>
>>> rule "RULE_ALL_RULES_HAVE_FIRED_ONCE_ORDINALLY"
>
>>> when
>
>>>     fact:InsertedFactPOJO()
>
>>>     InsertedFactPOJO(countdownLatch == 0) then
>
>
>
> Why not a single Pattern?
>
>     fact:InsertedFactPOJO(countdownLatch == 0) If (and only if) there is not
> more than a single InsertedFactPOJO in WM it doesn't matter (except confuse
> readers) but otherwise it produces more or less disturbing effects.
>
>
>
> -W
>
>
>
> _______________________________________________
>
> rules-users mailing list
>
> rules-users at lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> ________________________________
>
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions
> or views contained herein are not intended to be, and do not constitute,
> advice within the meaning of Section 975 of the Dodd-Frank Wall Street
> Reform and Consumer Protection Act. If you have received this communication
> in error, please destroy all electronic and paper copies and notify the
> sender immediately. Mistransmission is not intended to waive confidentiality
> or privilege. Morgan Stanley reserves the right, to the extent permitted
> under applicable law, to monitor electronic communications. This message is
> subject to terms available at the following link:
> http://www.morganstanley.com/disclaimers If you cannot access these links,
> please notify us by reply message and we will send the contents to you. By
> messaging with Morgan Stanley you consent to the foregoing.
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>