mjtravers
commented
4 months ago From CR:
The new aggregation code needs to take into account when a transaction record is edited so that it is removed from a calculation group. For example, if there is a group of 3 transactions for an entity aggregation and one of the transactions has its contact changed, only the updated transaction in its new group is aggregated. The other 2 transactions that were part of the original group are do not have their new aggregation sums without the transaction that was removed from the group recalculated.
To account for this scenario, the trigger code should factor out the window function rollups into separate functions. Then the trigger can call them once for the NEW row record and, if the record has changed so that it is in a new group, then the rollup function can be called on the OLD row record values to update the old group transactions. In Postres triggers, NEW and OLD are provided to the function as part of the Postgres API. See here.
Also, a couple of unit tests are broken and need to be fixed:
======================================================================
FAIL: test_serialize_f3x_summary_instance (fecfiler.web_services.dot_fec.test_dot_fec_serializer.DotFECSerializerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/opt/nxg_fec_e2e/fecfiler/web_services/dot_fec/test_dot_fec_serializer.py", line 173, in test_serialize_f3x_summary_instance
self.assertEqual(split_row[0], "F3XN")
AssertionError: '' != 'F3XN'
+ F3XN
======================================================================
FAIL: test_create_dot_fec (fecfiler.web_services.test_tasks.TasksTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/opt/nxg_fec_e2e/fecfiler/web_services/test_tasks.py", line 57, in test_create_dot_fec
self.assertEqual(lines[1][:5], "F3XN" + FS_STR)
AssertionError: '\x1cC000' != 'F3XN\x1c'
+ F3XN- - C000Sending ticket back to sprint backlog to be worked on by the next developer who has the bandwidth.
WiseQA
exalate-issue-sync[bot]
The aggregate calculations are currently being performed just-in-time during the transaction record READ operation.
This spike is to move the calculation from the view to the CREATE, UPDATE, and DELETE operations and save the result in the transactions_transaction table and see how it affects performance for the 3 calculations currently storing their results in the transaction view:
Since updating a transaction potentially impacts the aggregate of any transaction in it's topology/network, we need to do write an update that calculates the aggregates and updates the transactions. this should be doable with a single bulk update query that calculates the aggregates with a window function.
QA Notes
null
DEV Notes
null
Design
null
See full ticket and images here: FECFILE-181