Never duplicate any derived information while the data object holding the duplicate is still in the system. Given an invoice, you may associate its positions with a "tariff id", which lets you recalculate an (old) order repeatedly, guaranteeing stable pricing. Only when this data is removed from the system you actually calculate and use the currency values. -W 2011/4/17 Riyaz Saiyed <riyaz.saiyed(a)emirates.com&gt;

Ok, here is the scenario. If the selected product is “Product A”, If the adult count is between 1 and 5 Then price should be 50 USD per person. If adult count is between 6 and 10 the price Then the price should be 600 USD per group Now when the first time the product is booked for 5 adults, get the price 50 * 5 = 250 USD. In between price rule has been modified ad following. If the selected product is “Product A”, If the adult count is between 1 and 5 Then price should be 40 USD per person. If adult count is between 6 and 10 the price Then the price should be 700 USD per group When the next time the order is modified change the adult count and If the adult count is increased from 5 to 8, it should re-calculate the price to 600 USD as per previous rule. Or If the adult count is decreased from 5 to 3, it should re-calculate the price to 3 * 50 = 150 USD Thanks, Riyaz -- View this message in context: http://drools.46999.n3.nabble.com/Drools-Decision-Table-tp2830218p2833582... Sent from the Drools: User forum mailing list archive at Nabble.com.

The idea is to store these price rules as xls decision table. The admin (non technical guy) will periodically update the xls just to change the price. For example for the same date range - 1-Jan-2011 to 31-Mar-2011, price can be increased of decrease depending on the volume of requests. So creating multiple version (more entries in xls) may be time consuming for him. He will prefer to do "find and replace" to update the price. -- View this message in context: http://drools.46999.n3.nabble.com/Drools-Decision-Table-tp2830218p2833685... Sent from the Drools: User forum mailing list archive at Nabble.com.

The initial idea was to save a rule string as additional column in database with every booking request (against each product). Next time for any modification (for same product), I can create a .drl file from previously stored string at runtime and execute the rule again. -With best regards, Riyaz -- View this message in context: http://drools.46999.n3.nabble.com/Drools-Decision-Table-tp2830218p2834055... Sent from the Drools: User forum mailing list archive at Nabble.com.

Sorry, but I forgot an issue: - You will have to create a new knowledgebase, at least for each time an existing order is modified. Kbase creation is not a friend of perfomance. -- View this message in context: http://drools.46999.n3.nabble.com/Drools-Decision-Table-tp2830218p2834407... Sent from the Drools: User forum mailing list archive at Nabble.com.

The biggest issue you have to face, IMO, is getting your users to buy into a version control\governance process. Having them save changes as and when they see fit without some process surrounding it will lead to a life of pain. Any approach discussed here is a viable solution provided your users are willing to abide by some process. On 18 April 2011 16:20, Riyaz Saiyed <Riyaz.saiyed(a)emirates.com&gt; wrote:

Hi All 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 "). 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)).

You have to load them incrementally to the KnowledgeBase one at a time. You can have multiple RuleSets in one worksheet, please refer to documentation. probability of getting into performance related issues due to big knowledge base (Performance test matrix)? The first time you load all speadsheets into a KnowledgeBase will take sometime, there is no avoiding this. However once this has been completed once you can serialise the KnowledgeBase and therefore load much quicker on subsequent uses. I assume the rate of change of rules is much lower. On 24 April 2011 14:16, Riyaz Saiyed <Riyaz.saiyed(a)emirates.com&gt; wrote: