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