Some data about Simulation Motos
Table of Contents
Delivery Properties¶
1- each time a property or category can only be set at the order / delivery level it is most often a design mistake
2- any property which can be used to split / group movements must be defined on delivery lines / movements and acquired if necessary from parent delivery / delivery line
3- any property which can be the cause of divergence must be defined on delivery lines / movements and acquired if necessary from parent delivery / delivery lines
4- any property which can be the explanation of a split or merge request of deliveries (implemented through target solvers) must be defined on delivery lines / movements and acquired if necessary from
delivery / delivery lines
Conclusion: most if not all order properties will be movement to movements. This includes specialise, causality, etc.
getProperty and edit¶
The main purpose of getProperty and setProperty in ERP5 is to
1- act as helper to edit
2- mimic Zope original behaviour for property handling
An example was brought in which calling getPropery('specialise') was not giving the same result as calling getSpecialise(). In that example, getSpecialise(), as a method was acquired from parent object,
then returned the value on the parent. getPropery('specialise') was just returning the local property of the document (None).
Is this a bug or a feature. It is a feature. Why ?
1- implicit acquisition will be removed some day, you can not rely on it in this case (unlike in the early days of ERP5, where it was used a lot for indexing=
2- we do not want self.edit(specialise="whatever") to modify the parent object of self.
3- we want self.getProperty('specialise') to be consistent with self.setProperty('specialise')
Fastest Expand¶
Whenever expand is called on different applied rules of the same root applied rule, there is. a risk of reexpanding many times the same subtrees of the simulation tree, not to mention the risks of ZODB
conflict.
Proposed solutions to handle this:
- always reexpand from the root applied rule. This is great for small simulation trees but fails on large ones.
- always reexpand from a child of the root applied rule. Similar.
- always rexpend a single applied rule at a time, without forwarding, and forward expand as an activity. This is best to expand large simulation trees in parallel. But could be slow.
Which is the best? Still unknown.
Related Articles¶