[rules-users] Sequential mode and partial propagations

[Mark Proctor]

On 19/04/2011 18:58, Vincent LEGENDRE wrote:
> Hi All
>
> First : sorry for the misplaced reply to another thread
>
> This post is to continue an interresting (to me) discussion started 
> there : https://issues.jboss.org/browse/JBRULES-46
> This was about my remark about a backward-chaining mode that could be 
> used to allow sequential mode to handle some kind of RETE updates 
> (first rules could then trigger subsequent rules).
>
> There are some number of answers after that, but I am not sure if I 
> can answer them in the JIRA, so this post ...
>
>
> *To Mark :*
> "/Currently our sequential mode works as single pass, but it has no 
> inference as rete join memory is turned off. So it produces all the 
> conflict set more efficiently, and then it uses rule order for the 
> execution order of the conflict set. However changes in the current 
> rule are not recognised by the later rules. That is planned though by 
> "partinioning" the sequential engine around the modify statements. The 
> advantage to this is we keep a single algorithm that is just 
> configured slightly to provide different behaviours. Rather than two 
> competely different engines./"
>
> I think this is a very good solution, far much better (more efficient 
> and far more clear to predict how rules will fire) than handling 
> propagation for each individual rule's update. But I did not 
> understand if it is already done in trunk in some way, or if it is 
> something planned for future. And if so, the question after that is do 
> you have an idea of when this could be done ? ... or if is quite 
> affordable for someone not involved directly in drools developement? 
> (like me for instance, as you speak of "sligth configuration").
Sequential mode as in that text above is done. What is not done is the 
modify partitioning such that  later constraints see the updated values 
in the single pass - similar to what other products do. there are 
advantages and disadvantages to modify partitioning, but it's good to 
allow the user to have both :)
>
>
> To Michael :
> You propose some new rules, by binding the "something" field in 
> condition rather than calling getSomething() in action (and you change 
> the object to which is applied the update, which is an error I think).
> To me that changes nothing, the rule will loop as one of its binded 
> value is changed ($value, and now $something..). And a no-loop 
> property won't change this too ...
>
>
> To summarize a bit, the use-case I present in the JIRA (create 
> counters, fill them, validate them) could really take advantage 
> (perfs, simplicity in authoring/design) of a sequential mode that 
> could handle a partial inference (driven by a flow for instance, which 
> seems quite natural for everyone (dev or BA)).
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110419/ae00c270/attachment.html