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