In which table types can the values of the entire previous column be used in the code?
In fact, in all of them, but the approaches are different.
With a tabular recalculation unit (calculated and temporary)
In calculated and temporary ones, you can include the parameter column-by-column recalculation — it changes the order of field calculations.
Disabled — rows are calculated from left to right.
Enabled — columns are calculated from top to bottom (in ascending order of id or n).
The order of footer calculation for fields linked to columns also changes:
Disabled — fields are calculated in ascending order of sort and all after the row part.
Enabled — first, fields linked to columns are calculated in ascending order of the column's sort, and then in ascending order of the sort of fields linked to the column immediately after the calculation of all fields in the row part of the column (without waiting for the entire row part to be calculated!).
Why this might be needed. For example: we need to calculate the share of the value from the first column in the second column of the row part.
The code is as follows:
=: #first_column_value / #summ_first_column
We calculate #summ_first_column in the footer of the first column as:
=: listSum(list: $list)
list: selectList(table: $#ntn; field: 'first_column_value')
This will only work if column-by-column recalculation is enabled, because #summ_first_column must be calculated before the fields in the row part of the second column start to be calculated!
If column-by-column recalculation is disabled, then you cannot do the following in the code of the second column:
=: #first_column_value / $summ
summ: listSum(list: $list)
list: selectList(table: $#ntn; field: 'first_column_value')
Because rows are calculated from top to bottom, and at the moment when selectList is taken, the rows below do not yet exist!
With a row recalculation unit (simple and cycles)
For tables with a row recalculation unit, when you take selectList, this limitation does not apply because the rows in the table exist.
But there are features related to the current row. If this is an addition row, its values are not yet recorded in the database and will not be included in selectList. If it already exists and is being recalculated, the old values will be included.
Therefore, the current row is excluded from the select, and its value is added or included in the list by a separate action:
=: #first_column_value / $summ
summ: listSum(list: $list) + #first_column_value
list: selectList(table: $#ntn; field: 'first_column_value'; where: 'id' != #id)
// This will work for the addition row as well because != #id, which results in != "" in this case, also gives the desired result
What parameter should be included in the calculated and temporal tables, in order to get the correct values?
What should be noted when performing such a calculation in the insert row?
With table unit recalculation (calculated and temporary)
When Column-by-column recalculation is enabled, the value from the addition row will be included in the select automatically, even though the row has not yet been saved to the database.
With row unit recalculation (simple and cycles)
This does not happen, so the value of the current row is excluded from the select and added separately:
=: #first_column_value / $summ
summ: listSum(list: $list) + #first_column_value
list: selectList(table: $#ntn; field: 'first_column_value'; where: 'id' != #id)
How does the order of processing the footer fields change when you switch the calculation/temporary table to a column-by-column calculation mode?
The order of footer calculation for fields bound to columns is also changing:
Disabled — fields are calculated in ascending order of sort and all after the row part.
Enabled — first, fields bound to columns are calculated in ascending order of the column's sort, and then in ascending order of the sort of fields bound to the column immediately after the calculation of all fields in the row part of the column is completed (without waiting for the entire row part to be calculated!).