<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 19/04/2011 18:58, Vincent LEGENDRE wrote:
<blockquote
cite="mid:1616114965.4987.1303235930305.JavaMail.root@confiance.eurodecision.fr"
type="cite">
<style type="text/css">p { margin: 0; }</style>
<div style="font-family: Times New Roman; font-size: 12pt; color:
rgb(0, 0, 0);">Hi All <br>
<br>
First : sorry for the misplaced reply to another thread<br>
<br>
This post is to continue an interresting (to me) discussion
started there : <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/JBRULES-46">https://issues.jboss.org/browse/JBRULES-46</a><br>
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).<br>
<br>
There are some number of answers after that, but I am not sure
if I can answer them in the JIRA, so this post ...<br>
<br>
<br>
<strong>To Mark :</strong><br>
"<em>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.</em>"<br>
<br>
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").<br>
</div>
</blockquote>
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 :)<br>
<blockquote
cite="mid:1616114965.4987.1303235930305.JavaMail.root@confiance.eurodecision.fr"
type="cite">
<div style="font-family: Times New Roman; font-size: 12pt; color:
rgb(0, 0, 0);"><br>
<br>
<span style="font-weight: bold;">To Michael :</span><br>
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).<br>
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 ...<br>
<br>
<br>
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)).<br>
<br>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<br>
</body>
</html>