For example, to derive the balance as the sum of the unpaid order totals:
Derive balance as sum(purchaseorderList.amount_total where paid=false)
Sums are far quicker to define than Events, and they are quite efficient: adjustment is via 1-row updates, not expensive aggregate SQLs like
You define a sum via the Logic Designer. Click the Create New Rule, and select the Rule type and the table to which it applies.
Next, you define the parameters of the rule (further described below):
When complete, click Active and Close to return to the list of rules.
Your Qualification can include nulls, like this to check null (or != null):
The value of the attribute will be updated to reflect the sum of the specified attribute in the child objects whenever necessary. This includes child objects being added to and removed from the parent object, as well as modifications to the children objects that change their qualification in the Sum or the summed value. Observe that sum processing is triggered by changes to the child, as visible in the log.
A Sum is not recalculated from scratch, but rather adjusted as necessary. For instance, when a new (qualifying) child is added to the parent, the Sum attribute will be incremented by the child's amount. This means that there is very little performance impact.
To maintain high performance (per the adjustment discussion above), sum values are assumed to be correct on disk. So, if you define new sums on existing data, you need to initialize these for proper operation.
You can do that using SQL tools, like this.